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

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

Events to be processed in a thread are posted to a queue for that
thread and that threads semaphoe is posted to wake it up if nead be, 
so the notify functions run in that thread.  The thread that does the 
adding to that queue is the wrapper's thread.

Good point on pro_close_confirmation...  it does in fact need to be 
synchronus.  Bother.  

Mark was working on a non-threaded wrapper, which has some fairly
major reorganization, but he did not complete it as the customer
stopped paying, and he's been doing other things since.

The openssl question....  probably a bug in fact, but all the IO is in fact
handled in the same thread so probably not a locking problem yet, but
definitely a gotcha if that changes.

-bill

On Wed, Dec 10, 2003 at 03:26:37PM -0800, Lei Zhang wrote:
> 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
>