I have no direct experience with fork & exec on win32 but I would advice caution with both (especially fork) since IIRC they're both emulated on windows and probably not as well supported by the OS as on unix.
As a side note, if I read your post correctly, you're spawning a single thread from a CGI and I assume you want to have it keep on running after the CGI exits. Is there any reason then to start it from the CGI at all? You could probably avoid a lot of potential problems by starting the UDP server as a completely seperate process (say, as a windows service)
| [reply] |
...there are several fork/exec pairs. ... Is there anything I should be wary of?
Yes.
Forks on Win32 are emulated as threads, and to date the implementation
is a bit unreliable. I'd suggest looking into using
Win32::Process as an alternative.
Or possibly using Win32::Daemon, if your architecture is
going to need the shakeup I think it will
(As previously pointed out wrt Apache, your architecture will need some serious tweaking to do what you're attempting)
Perl Contrarian & SQL fanboy
| [reply] |
I was really hoping to get something functional using threads and function calls into the server. If it is standalone, then my scripts will need some hokey magic with message queues or some such interface. That is actually the current interface - a standalone server written in C waiting to accept udp messages, and when one is accepted, just do a system call with the contents of the message to launch a new browser with an argument of a new cgi script. Any way I can simplify the situation would be the best-case. The perl cgi scripts are driving the project, as they serve up html to a browser, and sockets from the main system need to interface and control things (both coming and going).
| [reply] |
If it is standalone, then my scripts will need some hokey magic with message queues or some such interface.
Why would it need that? Can you explain a little more about what this UDP server is supposed to be doing? I can't understand why you think it would be simpler to have a CGI script become a server.
That is actually the current interface - a standalone server written in C waiting to accept udp messages, and when one is accepted, just do a system call with the contents of the message to launch a new browser with an argument of a new cgi script.
There's no reason to use a system call to make an HTTP request. Just use something like LWP if that's what you need to do.
| [reply] |
You're trying to start a daemon from a CGI request? Don't do that. CGI scripts are not supposed to run forever. Make it a stand-alone script. | [reply] |