Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
    • by Matts (1087) on 2002.06.07 11:14 (#9296) Journal
      Asynchronous is inappropriate for PPerl - otherwise I would have used POE, and saved myself all these headaches.

      Plus much as Stem looks neat, it's not CPAN installable.
      • you can install it by running "perl" as root.

        Asynchronous isn't an issue. You can have a synchronous server with asynchronous code internally. Stem comes with a module, Stem::SockMsg that implements a socket-based listener. You use that and it feeds a message into your real server, which then replies. All the synchronous bits are managed by the Stem::SockMsg module.

        Having written such a thing (to interface to a client that is _not_ Stem-based) I can tell you its pretty darn easy to do.
        • PPerl needs to fork. It just can't work any other way - yes I guess the socket itself could be select based and fork after the connection and multiplex in the results, but that would be slower than a prefork model.
          • You can do prefork with Stem too.

            But you still need a single process listening on the socket that hands off the connection to the preforked processes, right?
            • No, you create your socket (binding it to the port), fork as many children as you hope to need, then call accept in each of the children. The OS decides which process to hand the connection to.
              • stem has a neat module Stem::WorkQueue that makes a prefork server easier. you can prefork a bunch of processes and send all the incoming requests to the queue which first-come/first-serves them to the process farm. or you can look at the existing inetd demo which is pretty much what you want and it requires no new coding. it forks on demand but unless you need to fork massively often it should be fine. if you must have a preforking server, it should be easy to code up with the process and SockMsg modules a
                • My major concern with using either Stem or POE with PPerl is that for PPerl I need access to the raw socket so that I can bind STDIN/ARGV and STDOUT directly to the socket. While I know I can do that with POE, it kind of circumvents the way POE is supposed to work. I'm not sure about Stem.