[interfacekit] Re: Asynchronous Mime Calls

[CCed to the IK team list, as it raises some questions about messaging, 
that may be of general interest.]

[...]
> > > Oh, also, as R5 implements it, if the calling process is
> > > terminated, the corresponding mime update thread also terminates.
> > 
> > If process means team, 
> 
> That is what I meant, but now that you mention, I don't actually know 
> what the behaviour is when you kill a single thread in a team that's 
> blocked on such a call.

For synchronous messages a reply port is reserved -- on libbe 
initialization three such ports are created -- and I suspect, that when 
a thread is killed while owning a reply port, this port remains 
unavailable to the rest of the team. Depending on how the ports are 
managed, such a situation may also be dealt with by added the port to 
the pool again, but then the entity that sends the reply, actually 
sends it to the wrong target, and all subsequent attempts to use that 
port will result in getting a wrong reply. That makes me wonder, how 
currently timing out synchronous messaging is handled -- it would cause 
the same problem.

Anyway, we have no chance to detect whether the requesting thread is 
still alive, unless we decide to supply its thread ID with the request 
message. I don't think it's worth the headache though. There will 
always be a race condition due to the time passing between the check 
whether the thread is still alive and the point when the message is 
sent. And, I believe, sending a message synchronously can be interruped 
by suspending+resuming the waiting thread.

CU, Ingo

Other related posts: