[MP-d] Re: Another mu-P question: sending messages with threads

[Stefan M. <me...@df...>]

-----BEGIN PGP SIGNED MESSAGE-----

Hi Mary and all!

Yesterday Mary Ellen Foster wrote:
> I'm still working on the local firewall issues; thanks for your help in 
> sorting that out! But now I've got a completely different mu-P question, 
> about sending messages from threads. If you guys aren't the right ones to 
> answer this question

Heinz is the right one for these questions. I included him in `Cc:'.
Also I included the Multiplatform developer list for the reasons
mentioned below. I hope you won't mind.

> I know that the mu-P classes themselves are not thread-safe. From looking 
> at other modules' source code, it appears that the thread-safe way to send 
> messages when threads are involved is to add the messages to an output 
> queue within the handlers, and to send those messages when the 
> waitForEvents() method. In pseudocode:
> 
> while( ! stopProcessing )
>     waitForEvents( timeout )
>         // within the event handler, we add messages to a queue
>         // of outgoing messages
>     while( queue is not empty )
>         send the next message on the queue, and dequeue it

If you are talking about Java this *might* be a correct solution. As
far as I can see things work if done in the same thread. In our
experience the problem with Java is that threads are created in rather
unexpected ways.

> Also, from my testing it seems that waitForEvents returns *either* when it 
> gets an event *or* when its timeout expires, whichever comes first. Is 
> that correct?

It depends. As documented a handler may return 0 or 1 to indicate
whether `waitForEvents' should be interrupted (1) or keep going (0).
May be this is even the answer to your question.

> Anyway, here's how I've been trying to write the pool-event handlers.
> 
> // Event handler
> handleMessage()
>     Create and start one or more threads in response to the message
>     Return immediately
> 
> // Within each thread
> run()
>     Do some (possibly lengthy) processing
>     Create one or more mu-P messages to be sent out,
>     and add them to the queue

The problem with this approach is that the execution context handling
the message is left soon - in particular independent of whether the
desired result has been accomplished or not. Of course this is good
for quick response time and introduces a nice asynchronuous behavior
of the module but unfortunately this asynchronuous behavior is
difficult to cope with. The message queue you mentioned seems one
possible solution though it has its drawbacks. In particular you may
end up in deadlocks which are broken only by the timeouts.

> Now, if I use the structure I defined above, it might be that the messages 
> created within a thread don't actually get sent until the next time the 
> waitForEvents() method times out, if there are no other events received in 
> the meantime.

Yes.

> It would be nice if there were some thread-safe way to get 
> the messages created in the threads to be sent "right away", without 
> having to use an extremely short timeout in waitForEvents().

Sure. May be Heinz can tell more here.

> Is this something that can be done within the architecture? Maybe by 
> interrupting the waitForEvents() method before its defined timeout, or 
> something like that?

The problem is that the underlying PVM does not handle threads. It
uses global message buffers (aargh!) and the like. We thought more
than once about introducing thread safety in the module manager but
never did it. In general there are two possibilites to do this:

* A global lock for the whole module manager which forces the calls
  from threads into a FIFO sequence

* Fine grained locks at the places which really need locking

The last seemed too complicated and the first too dumb.

However, the first solution would be dumb but one can expect a
manageable effort. Meanwhile there is

	multiplatform.sourceforge.net

where such patches could be added (for Comic that is when Peter gets
around to check in his Comic version of Multiplatform). Since this
question comes up again and again it's sure worth a try.

> Thanks very much!


						Hope this helps

						Stefan

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAgUBP6uN5QnTZgC3zSk5AQEXYwP/VeT/+mg3BzI4KsGc0cTGZV9vuBlUE8n/
EvxLTg2DcHmHUxS8n2qnjT80aJdqfxNe0wd2Q0tuFDWzoDSN8LQpUZNQMxl05gh6
wVrqtL/3I/prKGTwU58vWCwnzow8nydRYXiYOV0hyGGiQ1jMCe6l1i+rTGUCIcRc
KTw+Fs3mnko=
=s+0l
-----END PGP SIGNATURE-----