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. Regards, Carl On 29 August 2014 09:32, Chris Knipe <sav...@savage.za.org> wrote: > On Fri, Aug 29, 2014 at 10:10 AM, Carl Inglis <carl.ing...@gmail.com> > wrote: > > I suspect you're looking for something like this: > > http://www.perlmonks.org/?node_id=66135 > > > > In fact, it's specifically mentioned in the Perl Cookbook: > > http://docstore.mik.ua/orelly/perl/cookbook/ch07_15.htm > > The comments on the first URL is worrying, but I don't believe that it > would solve my issue. Lets take the following out of RFC4664 as an > example. This is an actual example of a communication stream between > a client and the perl server, the socket is already established, and > communication is flowing between the two parties. [C] indicates what > the client is sending to the server, and [S] indicates the responses > the server sends to the client. My comments added with # and thus > does not form part of the communication stream. > > [C] TAKETHIS <i.am.an.article.you.will.w...@example.com> > [C] Path: pathost!demo!somewhere!not-for-mail > [C] From: "Demo User" <nob...@example.com> > [C] Newsgroups: misc.test > [C] Subject: I am just a test article > [C] Date: 6 Oct 1998 04:38:40 -0500 > [C] Organization: An Example Com, San Jose, CA > [C] Message-ID: <i.am.an.article.you.will.w...@example.com> > [C] > [C] This is just a test article. > [C] . > # . indicates the end of the article. Perl now starts to do work, > processing the article it received. As this process takes time, the > main while (1) { loop reading from the socket is now blocked, causing > the server not to read any more from the socket until after the > article has been dealt with. > [C] TAKETHIS <i.am.an.article.you.h...@example.com> > [C] Path: pathost!demo!somewhere!not-for-mail > [C] From: "Demo User" <nob...@example.com> > [C] Newsgroups: misc.test > [C] Subject: I am just a test article > [C] Date: 6 Oct 1998 04:38:40 -0500 > [C] Organization: An Example Com, San Jose, CA > [C] Message-ID: <i.am.an.article.you.h...@example.com> > [C] > [C] This is just a test article. > [C] . > # Perl server only NOW responds with an acceptance code for the first > article. > [S] 239 <i.am.an.article.you.will.w...@example.com> > > We have effectively now COMPLETELY missed the second article in our > while (1) loop, as perl did not read from the socket WHILST processing > the article. > > When you multiply the above example and think that you can effectively > be receiving up to 100 (if not more) TAKETHIS commands per second, and > that it takes (on average) say 100ms to "deal" with an article > received... I'm sure you can understand the economics at scale here as > to why this is important, and what I mean by non blocking... > > The whole while (1) { read from socket; do work; respond; }; isn't > going to work. The moment you "do work", you block reading from the > socket until such time that the work has been completed. I don't > know how to be clearer about this. >
