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

[Steve Dobson]

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