479Re: [soaplite] Re: Fwd: Process-Pool Forking SOAP Server.
- Jun 16, 2001On Saturday 16 June 2001 18:22, Paul Kulchenko wrote:
> Hi, Michael!I called it 'Daemon' because it is a general purpose library that I am using
> > I believe that at least one moderate performance server should be
> > included in
> > the main distribution. Also, I think that it should be installed by
> > default,
> > without having to copy by hand from examples/ directory. I would
> Absolutely. I agree with you. I would like to include simple daemon,
> bulletproof daemon and nonblocking daemon.
> Your solution might work as bulletproof choice, however some
> modifications are still required. First of all, Daemon.pm shouldn't
in the rest of my project with other non-soap daemons. If you want to pull it
into your namespace, that is fine, though. It doesn't have any SOAP-specific
stuff in it, just utilites to manage pid files and log files.
> be Daemon, it might be SOAP::Transport::Daemon (because it'll provideOK. If you think my code is a good starting point, do whatever you think
> methods suitable for HTTP, TCP and other daemons). I would also like
> to add:
> 1. changing user and group ids
> 2. tainting
> 3. chroot
> 4. relaunch on signal
> Everything is optional, so you can choose whatever you need.
needs to be done with it.
I had been going about changing user/group id by making my soap.pl setuid to
the user/group I want it to run as.
What do you mean wrt tainting?
As far as relaunching on a signal, I had though about passing the ForkingSOAP
module a list of modules to 'require'. Then each time a child is spawned, it
'require's the list of modules. This way each child starts fresh with the
newest copy of the module. Then you could send a signal that makes the parent
kill all it's children and respawn them. Is this approximately what you were
- << Previous post in topic Next post in topic >>