[Sussex] the who/what/why/when of processes ( proc-i ? ;)

dunk fordyce him at dunkfordyce.co.uk
Thu Sep 5 13:43:00 UTC 2002


steve, this is pushing php a little - im using it more like perl, from the command line.
its actually a irc bot that sits there and listens and responds to commands.
i want to be able to start a new process for different rooms and also for things like searching the web ( i dont want the bot to stop responding while its searching ).

does that make more sense now?

On Thu, 5 Sep 2002 07:25:44 -0500
Steve Dobson <SDobson at manh.com> wrote:

> Geoff
> 
> Damn, you got there first.  Mine you I was having a nice lunch :-)
> 
> > From: Geoff Teale 
> > Dunk,
> > 
> > If you're C is upto scratch then this page is a good example. 
> >  It starts
> > with a program that does exactly the same as you PHP script.
> > 
> > http://www-h.eng.cam.ac.uk/help/tpl/unix/fork.html
> >
> > As far as handling multiple connections is concerned.  Well, this is
> > something Steve is going to be dealing with in INSIDE so it 
> > may be wise to have a word with him. 
> 
> Dunk's example code was in PHP (I think) but close enough to C that
> I could read it.  I therefore assumed that this was going to be a 
> browser plug-in or like.  Dunk can you clarify.  If you are planning 
> on this being a server side plug-in then we need to talk.  The page
> above doesn't details some of the other thinks that you have watch out
> for when forking from a complex parent.
> 
> > The simplest approach is to have a parent that forks every 
> > time it recieves a request.  This isn't the most efficient way of
> > doing things however -
> > starting new processes is quite "heavy" - for this reason a 
> > lot of systems use threads instead (this creates a whole bundle
> > of other problems especially in the use of shared memory).
> 
> Not so true these days.  The old version of fork was heavy.  Not
> only was the process entry copied but all the pages it was using.  As
> most calls to fork(2) were shortly followed by a call to exec(2) 
> there was a lot of work done for nothing.  I'll give details if anyone
> asks.  Now with copy on write handling by the kernel fork(2) itself is
> not that expensive, but still something to consider carefully before 
> doing.
> 
> Dunk:  I would like to "talk" about what you are trying to do here.
> I've have done a bit of work with fork(2) and threading, so I maybe
> able to pass on some of that knowledge.
> 
> > Another approach is some sort of pre-emptive process creation.  Some
> > servers launch processes in waiting so they are ready ahead of
> > requests (thus servicing the request more quickly).
> 
> Maybe - not so sure nowadays (see above).  I think when this sort of
> server became more common the kernal hackers improved the code.  With
> copy on write (with Linux 2.4 does) these types of servers will not see
> a big difference.
> 
> > For a good example of such a program why not take a little look at the
> > Apache docs, I'm sure somewhere it will discuss they're approach which has
> > been pretty damn successful.
> 
> Apache was one of the servers that showed where the kernel sucked.
> 
> > One good thing about Posix Forking is that it is the same across all
> > languages, C/C++, Bash Scripts.. everything.. it always works 
> > pretty much identically.
> 
> Not quite true.  They provide a framework everyone can code to.  Sun
> has vfork(2) operation were the child shares the parents address space.
> To stop race conditions the parent is blocked until the child calls
> _exit(2), exit(2) or exec(2).  Much faster to use than fork(2) as 
> it just takes over for a while.
> 
> Steve
> 
> _______________________________________________
> Sussex mailing list
> Sussex at mailman.lug.org.uk
> http://mailman.lug.org.uk/mailman/listinfo/sussex




More information about the Sussex mailing list