Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re^2: Thread::Queue and objects

by bronto (Priest)
on Jan 14, 2005 at 14:14 UTC ( #422238=note: print w/ replies, xml ) Need Help??


in reply to Re: Thread::Queue and objects
in thread Thread::Queue and objects

What is the problem you are encountering with the current method?

Suppose you run it on a very busy machine: even if short, the amount of time that passes from a timeouted accept and the new accept call could be long enough that a client tries to connect in between and finds nothing accepting on the socket. Not good...

--bronto


In theory, there is no difference between theory and practice. In practice, there is.


Comment on Re^2: Thread::Queue and objects
Select or Download Code
Re^3: Thread::Queue and objects
by BrowserUk (Pope) on Jan 14, 2005 at 18:40 UTC

    I see that there is a notional window there, but I think it only exists conceptually, if you only consider a single running thread at a time.

    On a single cpu machine, when any given thread is in that window between the accept timing out and the new accept being issued, every other thread, whilst dormant, still has an open accept on the same port (or is awaiting a timeslice to finish processing before re-issuing it's accept).

    If you have multiple threads running, the window in which all threads would be either processing data, or in between the timeout and the re-issue of the accept is vanishingly small.

    On a multi-cpu machine, even if you only have one more thread than cpus, the possibility of none of your threads having an accept in progress is pretty small.

    If you have double the number of threads as cpus, it becomes statistically very improbably.

    You have to realise, that even if a given thread has an accept in progress when the connect arrives, the odds are very high that it will not currently be in a timeslice. So most times, there will be a small delay between the connect occuring and the thread that accepts it getting a timeslice to complete the accept. This is true even of a non-threaded socket program running on a multi-tasking OS. So long as there is at least one thread that has an open accept, the tcp/ip stack / driver will accept the connect and 'hold' it until an appropriate thread or process gets a timeslice.

    The more threads you have issuing the accept on the appropriate port, the less likely that they will all be out of the accept wait state at the same time. It is not zero, but with even 5 threads, it is really very small.

    I'm not overly familiar with the detailed nitty gritty of tcp, but even in a traditional accept'n'fork model, there is a similar window between the accept occuring and it being re-issued. Even with a "dedicated" accept process, that process is still subject to being swapped at the schedulers convenience. It is only notionally "always running".

    I would say that that window is larger in the forking model, as even on COW optimised OSs, the process still has to be cloned, and then the new process will get the next timeslice. So the parent will have to wait until the new process finishes it's timeslice, plus any other processes that get schedule between times, before it will get a timeslice in which to go back and re-issue the accept.

    This doesn't seem to be an issue there, and I don't think the much rarer possibility, will be an issue in a threaded model.


    Examine what is said, not who speaks.
    Silence betokens consent.
    Love the truth but pardon error.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://422238]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (9)
As of 2014-12-26 06:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (165 votes), past polls