Re^8: Forking Clients

The main program doesn't need to know what the thread is doing in "real-time", just that its done, and when it is, the main program needs to get the results of whatever the thread did. The caveat here is that the main program just needs to be able to do other stuff while the thread is doing its thing.

I understand how I can spawn the thread/process have it do its thing if there is no need for the main program to get the resultant information back from the thread, but the issue I seem to be having is that I can't get the information back from the thread/process without blocking. I guess I am just not understanding how to implement the non-blocking properly

Btw, I thank you for the suggestions, I will look at both, the more I know the better.

Comment on Re^8: Forking Clients

Replies are listed 'Best First'.
Re^9: Forking Clients by mr_mischief (Monsignor) on Oct 16, 2008 at 19:30 UTC
If you need the information back at any point, then you have a few options. Sockets, named pipes, temporary files, a data store of some kind (RDBMS, tuple storage, LDAP, etc) or shared memory can work for forked processes. There are lighter-weight ways to pass the data between threads in a multithreaded process. If I was to take your original track of forking independent processes and needed the information back asynchronously, I'd probably use TCP sockets or a named pipe. I'd set the parent process up to listen and read without blocking using `select` and set the children up to connect back to the parent. The child can do what it needs, connect to the parent, dump its report across the socket, then exit. The parent can just ignore child processes exiting with `$SIG{'CHLD'} = 'IGNORE';`. To know which result is from which child, just have the child include its PID as part of the data it sends in its report. Any child that fails to report back within a certain number of seconds can be sent a kill signal and a new child can take its place in the queue. I think having the parent connect to each child is the wrong way to handle this, because you really only need one socket listening instead of one for each child.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^9: Forking Clients
by mr_mischief (Monsignor) on Oct 16, 2008 at 19:30 UTC

If I was to take your original track of forking independent processes and needed the information back asynchronously, I'd probably use TCP sockets or a named pipe. I'd set the parent process up to listen and read without blocking using select and set the children up to connect back to the parent. The child can do what it needs, connect to the parent, dump its report across the socket, then exit. The parent can just ignore child processes exiting with $SIG{'CHLD'} = 'IGNORE';. To know which result is from which child, just have the child include its PID as part of the data it sends in its report. Any child that fails to report back within a certain number of seconds can be sent a kill signal and a new child can take its place in the queue. I think having the parent connect to each child is the wrong way to handle this, because you really only need one socket listening instead of one for each child.

[reply]
[d/l]
[select]