Sockets. Threads, Demons...confused.

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Hi, I used to program Perl many years ago (and the fact that it was Perl  
4 isn't helping particularly :).

I am writing the spec for a Unix Demon process  and a corresponding CLI  
utility to interact with it. The tool will be implemented in C/C++, but  
I wanted to impress the engineering team with a fully working proof of  
concept in Perl. Things are not so simple as I was assuming, though. A  
few hours of hacking later, I am sort of stuck with issues that could  
probably greatly benefit from feedback from those who have specific  
experience in the field.
The Client will send in-band directives and the data through a TCP  
socket to the server. The server will respond with processed data (and  
in-band directives) though the same socket. The two programs often get  
stuck waiting for one another to send content down the pipe.


- My is using this code to await data and directives:

while (1) {
   $clientsocket = $socket->accept();
   while ($clientdata = <$clientsocket>) {

Is there a way to tell the system to do something else if no data is coming?

- Would it make sense to spawn sub-processes to handle each connecting  
client? What's the best way to achieve it? Proc::Daemon? should I look  
into threads?
Will I need to pass a reference to the socket to each sub-process/thread?

- Since the in-band directives effectively implement a protocol, I'll  
probably need to manage the state of both client and server at all  
times, to avoid that the two process get stuck waiting on one another.  
Is there a Perl module that helps with that?

I know this is a lot of stuff. Thanks in advance to those who can share  
their advice/experience...

Re: Sockets. Threads, Demons...confused.

On 11/26/2014 07:10, Luca wrote:
Quoted text here. Click to load it

open/listen/accept/IO::select/IO::can_read are all your friends.  Since you appear to be on
UNIX, I would think it would be a good idea to fork/exec off a process to handle the
transaction unless it just requires a simple response.

Check perlipc man page for additional insight or code for a simple server that someone
has already written for UNIX.

Site Timeline