[lug] Quote of the Day

[D. Stimits]

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).

> 
> People say "threaded" like it's an inherently good thing.  You get a
> different perspective on this when you program Java where you have to
> everything with threads...

Yes, this other person made the assumption that the design was because
of an inability for unix to thread, or inferior threading...it was
stated that windows uses threads in its IIS because of the superior
implementation there (I was thinking about selling him some swamp land).

> 
> Threads are another way of handling multiple things happening in a
> program.  Other ways are forking with IPC and select/poll
> multiplexing.  The Apache API actually does have the ability to
> do threading in it's lower-level platform-independent code, but
> that's not the way it goes for Unix.
> 
> Apache pre-forks processes and keeps a pool of processes that are
> ready to handle an incoming event.  If no fork is required on incoming
> connections, it doesn't matter if you're doing a heavy-weight process
> or light-weight thread as far as latency.

This person stated that the pre-forking was an indication of the
inferior ability of unix to properly thread. You are allowed to gag or
hurl here if you wish.

> 
> 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.
> 
> 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.

> 
> Perhaps threads are contributing to the instability IIS?  (The one client
> we have using IIS found their http server would just die about once a
> week).

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.

> 
> Sean
> --
>  "I want to see more of you around the lab."  "Fine.  I'll gain weight."
>                  -- Chris Knight, _Real_Genius_
> Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug