Why do Unix webservers typically use fork() instead of multi-threading?

bob@coolgroups.com wrote:
> Why do Unix webservers typically use fork() instead of multi-threading?

Perhaps aside from Java Web servers and roll-your-own, most don't fork() for
concurrency. Most are single process, and use asynchronous network I/O.

You're probably thinking of Apache. But the multi-process model is quite
common in general.

A more illuminating question might be why Windows network servers use so
much multi-threading.

Generaly speaking, unless you need to share many complex data structures
between threads of control, it's easier, simpler, and more robust (more
secure, for many definitions of secure) to employ multiple processes than
multiple threads w/ shared memory.

And often times when you do need to share complex data structures, you can
just use asynchronous I/O and a single thread of control.

In general, performance has nothing to do w/ it, other than people making
ill-informed decisions based on that factor.

>> Why do Unix webservers typically use fork() instead of multi-threading?

Because that's usually what you want.
An alternative question is -- why don't non-Unix webservers fork?

The aswer is usually that they don't support fork or that their process 
model makes fork() too expensive.

-- 
	mac the na�f

Alex Colvin <alexc@theworld.com> wrote:
> >> Why do Unix webservers typically use fork() instead of multi-threading?

> Because that's usually what you want.
> An alternative question is -- why don't non-Unix webservers fork?

> The aswer is usually that they don't support fork or that their process 
> model makes fork() too expensive.

I haven't voluntarily used a Windows computer since 3.11. But Vista and
Windows 7 finally have fork(), and though I won't switch, whenever somebody
tells me they don't like Vista, I exclaim, "but it has fork!" Of course, I
get confused looks, but they're intrigued by my enthusiasm.

IMHO, it's arguably the biggest advancement since Windows 95 joined Unix in
32-bit, protected-mode land. Fortunately, I had already jumped ship to Linux
before that happened. But for the first time I'm actually excited about a
new MS product. I wish it well, because it'll make my life easier writing
cross-platform software. Now, I just need WINE to pick up the pace chasing
Microsoft's APIs.

On 2009-02-08, William Ahern <william@wilbur.25thandClement.com> wrote:
>
> I haven't voluntarily used a Windows computer since 3.11. But Vista and
> Windows 7 finally have fork(), and though I won't switch, whenever somebody
> tells me they don't like Vista, I exclaim, "but it has fork!" Of course, I
> get confused looks, but they're intrigued by my enthusiasm.

[off topic]

Does it?! I've been coerced in the past to write cross-platform programs
that'll work on windows, and something like that would really help!

Since I've read your post, I've been skimming through the MSDN process
section and can't find something relevant, can you elaborate? Is it a
new system call, something like _fork (tough chance) or is it a new
parameter for CreateProcess?

Now if only the win32 PE linker/loader/whatever supported leaving symbols
unresolved in DLLs to be resolved at load time using symbols in the
process that loads them (like -rdynamic), I'd be on easy street :)

[/off topic]


-- 
John Tsiombikas (Nuclear / Mindlapse)
http://nuclear.sdf-eu.org/

On Feb 7, 7:06=A0pm, Alex Colvin <al...@TheWorld.com> wrote:
> >> Why do Unix webservers typically use fork() instead of multi-threading=
?
>
> Because that's usually what you want.
> An alternative question is -- why don't non-Unix webservers fork?
>
> The aswer is usually that they don't support fork or that their process
> model makes fork() too expensive.

With a multithreaded model (as opposed to fork) I would think you at
least get a tighter latency when you need to switch to another thread
to handle an event, since you don't have to flush the TLB along the
way. But admittedly I have no idea how much/little these cache misses
actually matter to the overall latency for a web server.

-Will

bob@coolgroups.com writes:
> Why do Unix webservers typically use fork() instead of
> multi-threading?

'UNIX(*) webservers' typically use any multiplexing facilities
available to them, depending on what the focus of development
was. Insofar this refers to Apache: The first Apache versions
exlusively used preforked processes and a dedicated process per
request (or connection), presumably, because this was the most
portable solution back then. This is still the default
'multi-processing module' for installation UNIX(*)- or UNIX(*)-like
systems.

As long as their isn't a specific reason to proceed otherwise, leaving
the defaults as they are usually make sense.

bob@coolgroups.com wrote:
> Why do Unix webservers typically use fork() instead of multi-threading?

Because it is easier to put a child in jail than a thread.

Because most of them were written before the thread libraries.

Because the programmers were more familiar with it.

Because that is the example in the book.

Some other dozen reasons.

Take your pick.

Rainer Weikusat wrote:
> bob@coolgroups.com writes:
>> Why do Unix webservers typically use fork() instead of
>> multi-threading?
> 
> 'UNIX(*) webservers' typically use any multiplexing facilities
> available to them, depending on what the focus of development
> was. Insofar this refers to Apache: The first Apache versions
> exlusively used preforked processes and a dedicated process per
> request (or connection), presumably, because this was the most
> portable solution back then. This is still the default
> 'multi-processing module' for installation UNIX(*)- or UNIX(*)-like
> systems.

Since apache supports 3rd party loadable modules, bad code will only zap
one process at a time. Requests not using the bad module will always work.

-srp

Golden California Girls wrote:
> bob@coolgroups.com wrote:
>> Why do Unix webservers typically use fork() instead of multi-threading?
> 
> Because it is easier to put a child in jail than a thread.
> 
> Because most of them were written before the thread libraries.
Don't you mean "during the period in which threading fell out of favour 
(aka the perceived decline of the mainframe, Burrough's machines had 
thread in the 70's (or possibly even the 60's))."

	Cheers,
		Gary	B-)

-- 
______________________________________________________________________________
Armful of chairs: Something some people would not know
                   whether you were up them with or not
                                      - Barry Humphries

Gary R. Schmidt wrote:
> Golden California Girls wrote:
>> bob@coolgroups.com wrote:
>>> Why do Unix webservers typically use fork() instead of multi-threading?
>>
>> Because it is easier to put a child in jail than a thread.
>>
>> Because most of them were written before the thread libraries.
> Don't you mean "during the period in which threading fell out of favour
> (aka the perceived decline of the mainframe, Burrough's machines had
> thread in the 70's (or possibly even the 60's))."

You were writing *WEBSERVERS* in the 60's and 70's?

Golden California Girls wrote:
> Gary R. Schmidt wrote:
>> Golden California Girls wrote:
>>> bob@coolgroups.com wrote:
>>>> Why do Unix webservers typically use fork() instead of multi-threading?
>>> Because it is easier to put a child in jail than a thread.
>>>
>>> Because most of them were written before the thread libraries.
>> Don't you mean "during the period in which threading fell out of favour
>> (aka the perceived decline of the mainframe, Burrough's machines had
>> thread in the 70's (or possibly even the 60's))."
> 
> You were writing *WEBSERVERS* in the 60's and 70's?
The subject is "fork", with a web server just being an example of fork 
versus threads.

	Cheers,
		Gary	B-)

-- 
______________________________________________________________________________
Armful of chairs: Something some people would not know
                   whether you were up them with or not
                                      - Barry Humphries

John Tsiombikas <nuclear@siggraph.org> wrote:
> On 2009-02-08, William Ahern <william@wilbur.25thandClement.com> wrote:
> >
> > I haven't voluntarily used a Windows computer since 3.11. But Vista and
> > Windows 7 finally have fork(), and though I won't switch, whenever somebody
> > tells me they don't like Vista, I exclaim, "but it has fork!" Of course, I
> > get confused looks, but they're intrigued by my enthusiasm.

> [off topic]

> Does it?! I've been coerced in the past to write cross-platform programs
> that'll work on windows, and something like that would really help!

> Since I've read your post, I've been skimming through the MSDN process
> section and can't find something relevant, can you elaborate? Is it a
> new system call, something like _fork (tough chance) or is it a new
> parameter for CreateProcess?


*sigh* I think somebody played a very cruel joke on me. I could _swear_ I
remember reading it on one of the Vista features articles on Wikipedia, but
I can find no trace of it. I even vaguely remember reading about it on MSDN.
Maybe I deluded myself--mirages in the desert. :(

Golden California Girls wrote:
> Gary R. Schmidt wrote:
>> Golden California Girls wrote:
>>> bob@coolgroups.com wrote:
>>>> Why do Unix webservers typically use fork() instead of multi-threading?
>>> Because it is easier to put a child in jail than a thread.
>>>
>>> Because most of them were written before the thread libraries.
>> Don't you mean "during the period in which threading fell out of favour
>> (aka the perceived decline of the mainframe, Burrough's machines had
>> thread in the 70's (or possibly even the 60's))."
> 
> You were writing *WEBSERVERS* in the 60's and 70's?

     He'll release the beta Real Soon Now, as soon as he's
fixed the last bug ...

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Gary R. Schmidt wrote:
> Golden California Girls wrote:
>> Gary R. Schmidt wrote:
>>> Golden California Girls wrote:
>>>> bob@coolgroups.com wrote:
>>>>> Why do Unix webservers typically use fork() instead of
>>>>> multi-threading?
>>>> Because it is easier to put a child in jail than a thread.
>>>>
>>>> Because most of them were written before the thread libraries.
>>> Don't you mean "during the period in which threading fell out of favour
>>> (aka the perceived decline of the mainframe, Burrough's machines had
>>> thread in the 70's (or possibly even the 60's))."
>>
>> You were writing *WEBSERVERS* in the 60's and 70's?
> The subject is "fork", with a web server just being an example of fork
> versus threads.

>>>>> Why do Unix webservers typically use fork() instead of
>>>>> multi-threading?
Somehow I think my English teacher would disagree with you.  But feel free to
diagram it.

William Ahern <william@wilbur.25thandClement.com> wrote in
news:3sv666-aev.ln1@wilbur.25thandClement.com: 

> John Tsiombikas <nuclear@siggraph.org> wrote:
>> On 2009-02-08, William Ahern <william@wilbur.25thandClement.com>
>> wrote: 
>> >
>> > I haven't voluntarily used a Windows computer since 3.11. But Vista
>> > and Windows 7 finally have fork(), and though I won't switch,
>> > whenever somebody tells me they don't like Vista, I exclaim, "but
>> > it has fork!" Of course, I get confused looks, but they're
>> > intrigued by my enthusiasm. 

>> Does it?! I've been coerced in the past to write cross-platform
>> programs that'll work on windows, and something like that would
>> really help! 
> 
>> Since I've read your post, I've been skimming through the MSDN
>> process section and can't find something relevant, can you elaborate?
>> Is it a new system call, something like _fork (tough chance) or is it
>> a new parameter for CreateProcess?
> 
> 
> *sigh* I think somebody played a very cruel joke on me. I could
> _swear_ I remember reading it on one of the Vista features articles on
> Wikipedia, but I can find no trace of it. I even vaguely remember
> reading about it on MSDN. Maybe I deluded myself--mirages in the
> desert. :( 

The "NT native API" underlying the Win32 API supports the equivalent of 
fork() and always has.  Unfortunately, Microsoft has never provided 
enough public documentation of this API to make it easily usable.  See 
this discussion:

http://groups.google.com/group/microsoft.public.win32.programmer.kernel/
browse_frm/thread/7a3b4709999dc9a2
[http://tinyurl.com/bhqrr8]


There is also a published book that describes the native api.

http://books.google.com/books?id=Fp1ct-
bKYdcC&printsec=frontcover&dq=windows+2000+native+api
[http://tinyurl.com/b2esq3]

GH