On Fri, Aug 29, 2014 at 10:43 AM, Carl Inglis <carl.ing...@gmail.com> wrote: > Hi Chris, > > The only way this is going to work as far as I can see is some form of > multi-threading - how about you have a thread which issues the commands, a > thread which reads from the sockets and shoves the results into a queue, and > another thread which processes that queue. > > I think you're looking for a single threaded solution to an implicitly > multi-threaded problem. I can't see any way for a single thread to do what > you want.
Not specifically looking for a single threaded solution - looking for *any* solution. This is why I am saying, there really isn't anything in terms of examples, cookbooks, etc. dealing with something like this. This is really simple asynchronous communication at the end of the day - in my books at least. Through my searching I've stumbled onto something on perlmonks (I think) basically where there was a thread to read from the socket, and a thread to write to the socket, but it was advised against doing that for some reason or the other - I'll see whether I can get the link again in the browser history or something. At the end of the day I suppose, see this as an opportunity (for the mainstream developers). Whilst it will most certainly complicate things, native support for things like this in POE, or Net::Server, or Net::IO::Socket would really be appreciated. We are in the 21st century afterall. IMHO the days synchronous communication are long gone. And again, I mean this with the utmost respect :-) In the case of POE or Any::Event (if my memory serves me correctly), one should surely be able to "offload" the "work" through an event handler in a non blocking way, and write back to the socket at any time? That was my understanding of it at least - and guess my surprise when that was not the case. Who knows, perhaps it is possible and I'm just overlooking it too. Multi-Threading and queueing is a option. The first thing that crops up in my head again now though is that *IF* you receive data faster than what you can process it, you're now looking at OOM issues again. Secondly sitting with say, 1K forks from Net::Server and each fork sitting with 2 or 3 Threads - the poor server is all that I'm going to say... Perhaps the simplest (and what I didn't want to do), is to just dump it to a spool directory on disk and have a completely separate daemon pickup and process the files from disk... At least then you can read the list of files, spawn say 30 or 40 threads, and deal with the files - quickly - say every minute or two. The server can also if needs be I suppose fork through a non blocking sub to write the files to disk, so the server doesn't even need to wait for the IO operation. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
