PHWinfo - Afficher un message

29/03/2006, 19h23

Mike - EMAIL IGNORED <m_d_berger_1900@yahoo.com> wrote:
>> What leads to the potential excessive delays before the recv? Is the
>> "signal" not acted upon until the thread has come-out of the heavy
>> number crunching routing? If so, why not simply have that thread try
>> a non-blocking recv() on that socket, if something is there, process
>> it, otherwise, go back and do more number crunching and try again
>> later.

> Sounds good. How would I estimate how frequently I should do this?

Presumeably, however often the compute thread(s) check the condition
variable in the existing scheme.

> As I think about this, I am wondering if moving all the recv
> calls to the select thread, and send the received data to
> the process thread (of course with smart pointer, etc, to
> avoid repeated memcpy).

> What do you think?

I think it means that processing the message requires two context
switches when it could just need one if the thread that was going to
process the message was the one to read it (without a select).

Now, if the number of sockets becomes greater than the number of
threads or whatnot, and there is no reasonable way to divvy-up the
sockets among the threads it may indeed be necessary/desirable to
separate things a bit.

>> I suspect that the check the number crunching thread would do to
>> check for your "signal" may not be all that much better than the
>> non-blocking recv() call.

> Interesting, but this would preclude use of "signals" from
> other threads.

If the compute threads have to communicate with one another, if the
communication is sufficiently "rare" perhaps they could communicate
via (non-blocking) sockets themselves. If the communication is more
frequent, then mutexes and condition variables may be more efficient.

>>
>> Is there a requirement for a timely "ACK" to the message if not a
>> completed response?
>>

> Not unless something about the tcp protocol requires it.
> If there were such a need, the processing thread could send
> a an application-level ACK.

That would depend on how long it "processed" before grabbing the
message right? I asked because if the remote needed some sort of
quick reply, then you might indeed want the selecting thread to do the
recv and generate the application-llevel "we're working on it" ACK.

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway...

feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

29/03/2006, 19h23	#4
Rick Jones Messages: n/a Hébergeur:	Re: tcp socket placement in threads Mike - EMAIL IGNORED <m_d_berger_1900@yahoo.com> wrote: >> What leads to the potential excessive delays before the recv? Is the >> "signal" not acted upon until the thread has come-out of the heavy >> number crunching routing? If so, why not simply have that thread try >> a non-blocking recv() on that socket, if something is there, process >> it, otherwise, go back and do more number crunching and try again >> later. > Sounds good. How would I estimate how frequently I should do this? Presumeably, however often the compute thread(s) check the condition variable in the existing scheme. > As I think about this, I am wondering if moving all the recv > calls to the select thread, and send the received data to > the process thread (of course with smart pointer, etc, to > avoid repeated memcpy). > What do you think? I think it means that processing the message requires two context switches when it could just need one if the thread that was going to process the message was the one to read it (without a select). Now, if the number of sockets becomes greater than the number of threads or whatnot, and there is no reasonable way to divvy-up the sockets among the threads it may indeed be necessary/desirable to separate things a bit. >> I suspect that the check the number crunching thread would do to >> check for your "signal" may not be all that much better than the >> non-blocking recv() call. > Interesting, but this would preclude use of "signals" from > other threads. If the compute threads have to communicate with one another, if the communication is sufficiently "rare" perhaps they could communicate via (non-blocking) sockets themselves. If the communication is more frequent, then mutexes and condition variables may be more efficient. >> >> Is there a requirement for a timely "ACK" to the message if not a >> completed response? >> > Not unless something about the tcp protocol requires it. > If there were such a need, the processing thread could send > a an application-level ACK. That would depend on how long it "processed" before grabbing the message right? I asked because if the remote needed some sort of quick reply, then you might indeed want the selecting thread to do the recv and generate the application-llevel "we're working on it" ACK. rick jones -- denial, anger, bargaining, depression, acceptance, rebirth... where do you want to be today? these opinions are mine, all mine; HP might not want them anyway... feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...