Re: Thread::Queue and objects

I am going to have no luck with this approach, am I?

The best answer I can give is that I haven't succeeded in doing this--and I have tried quite hard.

I think that the documentation for Thread::Queue (and much of the other threads-related documentation) still has some vestigies of the original 5.6.x pthreads information lingering.

I did read somewhere (not on this site I think), that it is possible to re-bless an object into a different thread. Apart from that threads::shared will not allow you to share blessed references, theoretically you ought to be able to have a copy of the class loaded in two threads and by re-blessing an object reference created in one, into the other, have both threads access copies of the same object.

I see all manner of problems with synchronisation and locking inherent in this. I did make a half-hearted attemt to verify this was possible, but I got nowhere. Again, it could be that what I read was only applicable to pthreads not iThreads.

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

If you do find another way, please post it here. Thanks.

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

Comment on Re: Thread::Queue and objects

Replies are listed 'Best First'.
Re^2: Thread::Queue and objects by bronto (Priest) on Jan 14, 2005 at 14:14 UTC
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 `accept`ing on the socket. Not good... `--bronto` In theory, there is no difference between theory and practice. In practice, there is.	[reply] [d/l] [select]
Re^3: Thread::Queue and objects by BrowserUk (Patriarch) 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.	[reply]


No such thing as a small change
	PerlMonks