Re: [Beepcore-c-users] threading: is lock needed in pro_message_available

[William J. M. <wm...@es...>]

The way the C implementation works each profile may be instantiated
as thread-per-channel or working in a common worker thread.  Events
for a channel are queued in the work queue for that channel, with the
shared work thread getting all events that odn't have thread-per-channel
in the order that they are recieved.

Your observation is correct, that the channel gets notifications sequentially
and in most implementations it's doing the work itself.  It would be possible
for a channel to maintain it's own thread, and simply enqueue events when
the notify function is called, and could process them in a more non-blocking
fashion.  Remembering of course that you are bound by the ordering restrictions
for MSG processing.

Does that help?

-bill

On Thu, Dec 04, 2003 at 11:57:33AM -0800, Lei Zhang wrote:
> Howdy,
> 
> I've been digging the wrapper code to no avail for answer to a simple 
> question: it seems each incoming message gets delivered to the 
> application via a different thread, should I use lock to protect 
> critical section in pro_message_available?  Some testing shows that the 
> application gets notified about an incoming message only after it has 
> finished sending RPY to the previous message - is this observation wrong?
> 
> Any hint is immensely appreciated.
> Lei
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users