Bijan Parsia <bparsia at email.unc.edu> wrote:
> > Bijan Parsia <bparsia at email.unc.edu> wrote:
> > > Right now, it's *impossible* to write a web
> > > server/web application that can handle multiple simlultanous
requests
> > (at
> > > least, on the mac). 
> > 
> > Why can't it?  I just tried, and I'm downloading two different
versions
> > of osprocess off of the Squeak swiki, which is running on a mac. 
Both
> > download progress bars are updating simultaneously.
> 
> We're the *requests* truely simultaneous? Yes, the *serving* can
happen,
> but there is a period after receiving a request wherein the sever
refuses
> connections. C'mon. We see this all the time on the Squeak Swiki
(which
> has multithreaded PWS processing, so *that's* not what's causing
> difficulty).
> 

No, but you just said "simultaneous" requests, so it wasn't clear what
you meant.  The more specific feature you describe is indeed important
on a busy server.

However, the necessary primitive for it is now in; one just needs to
lobby some Mac programmer or another to try and implement it.  (It looks
like this is happening).  And incidentally, minnow has an unrelated
problem lately: it seems to have decided that 4 sockets are enough for
anyone.  This is odd, because other Mac servers will allow many more
connections to be open at once.


[ networking is unstable on Bijan's Macs ]

Ahhh, you've been seeing a lot of crashes.  That's not good.  Have you
tried hashing out what went wrong over on the pws list?  Perhaps
ConnectionQueue was running out of sockets and busy looping.  We (Tech
squeakers) have a patch that keeps this from becoming a hard crash, if
this is the problem.  Hopefully this patch becomes a squeak default
eventually.

In any case, this thread started out about rehashing sockets for
performance reasons, and I had thought you were complaining that current
Squeak's are too slow for practical use.  I now see that you are
complaining about stability, which is important but different.

The biggest stability bugs we've found at GT have been in dealing with
the situation where sockets have run out.  The second biggest problem is
in the way sockets are shut down; TCP is picky about how it's down, and
if you do it wrong, the connection will get aborted early.  We've done a lot
of beating on Squeak networking, and not seen a need for any primitives
other than the listenOn:backlog: one that got added recently.


Lex