Well - in this instance our "PARENT" is an agent that needs to run on
any system and accepts/handles requests from remote clients to execute
other tasks. We use it in an automated testing tool we sell. We can't
require the complex infrastructure of Apache be installed on each system
where a customer might want to put an agent.
T. William Schmidt wrote:
I am curious why you wrote your own server? Why didn't you use Apache
and mod_perl? Before I discovered Apache I wrote perhaps 3 dozen UNIX
daemons in C following the TCP/IP concurrent server model to provide a
variety of services. Most fronted RDBMS, some implemented gateways to
MVS and a few contained specialized search engines. When I discovered
Apache I thought I might lift some code to improve my servers,
particularly the pre-forking of handlers and the load balancer. Then
I discovered Apache modules and the Apache C API, which led me to
mod_perl, and I wrote my last daemon.
At 05:18 PM 10/14/2004 -0700, $Bill Luebkert wrote:
Shane McCarron wrote:
> This would definitely work - we do it now to emulate "background"
> execution. However, we have a related problem that hopefully someone
> has solved. Consider this model:
>
> CLIENT <--> PARENT <--> CHILD
> <--> CHILD2
> <--> CHILD3
>
>
> The PARENT process is a daemon written in perl that is listening for
> incoming requests to perform various tasks. As those requests come
in,
> PARENT needs to start up CHILD scripts (or executables - doesn't
really
> matter) and then communicate with those CHILD processes via STDIN and
> STDOUT (think something interactive like "bc"). When the CHILD
> completes, we clean it up and wait for more requests. While it is
> running, the CLIENT might be polling the PARENT for status, or sending
> instructions to start new CHILDren or whatever.
>
> On UNIX/Linux, we achieve this using select and it works very
well. On
> Windows, apparently select does not work on "files", only on sockets.
> We are tearing our hair out trying to resolve this, but so far no joy.
> Does anyone have any suggestions?
1) Use sockets with the children (a fair amount of coding).
2) Use files and poll the files for size changes (sloppy and not
event driven).
3) Use shared memory (not a good choice since the only version is
unsupported).
4) Do it all in the parent and forget the children (a matter of
including
the child code into the daemon and where you would normally send a
cmd to
the pipe, just call the child sub (make sure the child doesn't
lock up
the task).
I would probably be tempted to use 4), but 1) should also be feasible.
In any case, I wouldn't use fork if children are involved (use
Win32::Process).
--
,-/- __ _ _ $Bill Luebkert
Mailto:[EMAIL PROTECTED]
(_/ / ) // // DBE Collectibles Mailto:[EMAIL PROTECTED]
/ ) /--< o // // Castle of Medieval Myth & Magic
http://www.todbe.com/
-/-' /___/_<_</_</_ http://dbecoll.tripod.com/ (My Perl/Lakers stuff)
_______________________________________________
ActivePerl mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Regards,
Will Schmidt
WilliamSchmidt.com, LLC
11201 NW 77th Street
Terrebonne, OR 97760
541 504-0290
[EMAIL PROTECTED]
http://www.williamschmidt.com/
--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: [EMAIL PROTECTED]
_______________________________________________
ActivePerl mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
