Menu
▾
▴
beepcore-c-users
|
From: Lei Z. <lz...@ju...> - 2003-12-04 19:57:40
|
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 |
|
From: Huston <hu...@us...> - 2003-12-06 18:26:53
|
Lei, From what I recall your observations are correct. It would take a bit of looking to track this down because of how the synchronization/locking was implemented. --Huston ----- Original Message ----- From: "Lei Zhang" <lz...@ju...> To: <bee...@li...> Sent: Thursday, December 04, 2003 12:57 PM Subject: [Beepcore-c-users] threading: is lock needed in pro_message_available > 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 > > |
|
From: William J. M. <wm...@es...> - 2003-12-09 22:30:10
|
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 |
|
From: Lei Z. <lz...@ju...> - 2003-12-10 23:27:14
|
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 >>Bee...@li... >>https://lists.sourceforge.net/lists/listinfo/beepcore-c-users >> > > |
|
From: William J. M. <wm...@es...> - 2003-12-11 00:45:25
|
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 > |
Thanks for helping keep SourceForge clean.
X