[lug] Quote of the Day

[rm at mamma.varadinet.de]

On Tue, Jan 30, 2001 at 06:38:49PM -0700, D. Stimits wrote:
> Sean Reifschneider wrote:
> > 
> > On Tue, Jan 30, 2001 at 04:14:13PM -0700, D. Stimits wrote:
> > >because unix doesn't thread right, that the threads were just forks. I
> > >guess he didn't understand the implications of a connectionless protocol
> > >like http, and it sounded good.
> > 
> > HTTP is connectionless?!?  How do you mean?  It uses TCP...  Do you mean
> > stateless?
> 
> Stateless is a better descrip. Hits are serviced, and it then
> disconnects (options can be used to force a maintained state, if the
> server allows it, but is not the norm here).

As a matter of fact, with HTTP1.1 the underlying connection
is 'statefull' (meaning: it stays open) while the protocol itself
is stateless (this is to avoid the overhead of constantly re-
establishing connections on the network/transfer layer).

[...]

[Sean:]
> > You can implement the algorithms in any of these ways, it just depends
> > on what you're most comfortable with and what fits the job best.  For
> > example, I implemented a multi-plexed SMTP sink which was blazingly
> > fast.

Well, as apache shows this is possible, but i think we should try
to give credit to threading where it deserves. If your application
needs to share a lot of dynamic data between several instances of
'doers' threading does have some nice advantages. While this is
certainly possible with processes (via IPC/shared memory/messages/se-
maphores ...) the code starts to look rather uggly. 

> > However, forking does have one kind of nice advantage.  If the process
> > handling a connection dies or freaks out for some reason, it doesn't
> > impact any other connections or the server overall.  Not necessarily
> > true with threads or multiplexing.
> 
> This is the one perceived advantage that the culprit admitted to, for
> forking, but he considered it a side-effect of inability to thread, and
> not design intent.

... as long as the process doesn't share data structures with others.
Unfortunately, SysV IPC mechanisms don't have a 'cleanup-on-exit'. So,
while your OS of  choice does release resource like filehandles etc.
IPC resources aren't released. You need special utilities like 'ipcs'
and 'ipcrm' to do the cleanup (i recall older versions of postgresql
that needed manual cleanup every time a backend process died).


[...]

> Yes, at my prior job there were several server hangs that threading was
> a problem with. It created an inability to unload the dll responsible as
> well, and forced the entire machine to be rebooted since the dll could
> not be unloaded. But that isn't so much threading as it is weak spots in
> the IIS thread design; well-designed threading could have prevented the
> need to reboot upon error.

I have seen similar things with threading problems in Java apps.
It usually is a combination of bad programming and the rather complex
interaction of threads (most programers forget that even without im-
plicit threads in their apps the JVM runs several threads anyway), resource
locking and garbage collection.
Forking seems to keep people from doing nasty things unless they
really know how to ...

 Ralf