Re: threading: is lock needed in pro_message_available

Actually my goal is not to make the wrapper more non-blocking. 
 'pipelining' is not a good thing for the profile I'm developing.

With the thread management hidden so well in the wrapper, it's hard to 
tell from which thread those profile callbacks are called - and if any 
lock is needed to protect data structure such as PRO_LOCALDATA.  Even if 
"it would be possible for a channel to maintain its own thread', the 
pro_close_confirmation() still will get called from a thread other than 
the thread of the channel's.  IIRC, somebody asked about the 
availability of a non threaded wrapper months ago - is there such a 
wrapper available now?

Another question: the openssl FAQ says: if the ssl library is to be used 
in a MT application, a couple of CRYPTO_* functions should be called to 
setup the ssl library locking mechanism.  But I don't see these CRYPTO_* 
functions in beepcore-c - is it because all the socket I/O is handled by 
a single thread, so that there is no need to do the CRYPTO_* setup?

Thanks,
Lei

  Even if William J. Mills wrote:

>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
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
>>
>
>





-------------------------------------------------------
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/