🚀 go-pugleaf

> Excerpts from netnews.comp.os.mach: 6-Mar-90 summary: timeout on
> conditi.. Eric Hammond@kgw2.bwi.WE (5567)

> I'm going to be attacking the problem using (5) and (5b).  I am not
> absolutely sure about the comment I made " a msg_send() to PORT_NULL
> has no effect".  The worst I could see it doing would be to return
> the "invalid port" error which could be ignored.  I'd like to hear
> from someone who knows.


Sending a message to PORT_NULL will result in a SEND_INVALID_PORT error.
 The msg_send will have no effect.  (This is not true of all msg-send
errors.  For example, if there is a problem somewhere in the body of a
message, and a previously parsed piece of the message sent out-of-line
memory with the deallocate option, then the memory will be deallocated
when the msg-send returns the error.)

If you plan to use msg_receive with a timeout, and you care about the
accuracy of the timeouts, there are some "features" you should be aware
of.  If a msg_receive is interrupted, say because of a signal, then the
system call is interrupted and restarted unless the RCV_INTERRUPT option
is used.  However, when the msg-receive is restarted, it resumes with
the original timeout.  So if you do a receive with a 10 second timeout,
and have a 1 second interval timer, the receive will never timeout
because it will restart every second with another full 10 second timeout.

If this is a problem for you, you should use the RCV_INTERRUPT option so
you regain control when the msg-receive is interrupted (with a
RCV_INTERUPTED return code), and then you can calculate the correct
timeout value for the retried msg-receive.

Rich