Re: RES: package system modification (module loaders)

[Mike Pall <mikelu-0501@...>]

Hi,

John Skaller wrote:
> Yup, but select() and poll() aren't scalable.

Sure. But for what LuaSocket is designed for, it's perfectly ok. When you
get even close to the numbers where you get into trouble there is a lot
more that needs to be fixed (e.g. buffer management -- kernel and user side
and other internal API issues).

> Event based notification is O(1). I saw some talk
> of a signal based system for Linux to allow proper
> asychronous I/O.

A Talk? I guess you missed a few years of OS development. You don't read
kernel diffs regularly by any chance? Hint: Linux has epoll() and *BSD
has kqueue().

> Searching an array of 100 sockets wouldn't be a problem.
> However, what if you needed 100K? That's just about
> the rating of a commercial telephony switch:
> 600 call/sec * 3 minutes = 108,000 calls.

You forgot to mention that telephony switches do not have traditional
kernels, do not use the traditional socket API, usually do not use TCP
and certainly do not use select(). This comment is off-topic wrt LuaSocket.

Google for C10K and please resist the urge to post any more on this topic
before you read through it.

> Note that using poll() or select() there is no need
> to do non-blocking I/O -- since you know which sockets
> have data to read you can do a blocking read, and predict
> it won't block .. :)

Bzzzt. Wrong answer. Even introductory texts on the topic of async
socket I/O tell you that this is just not true. Advanced texts (if you'd
care to read them) would tell you why this is true (hint: the API is
not race-condition free). Practical experience would tell you that it
happens quite often.

> OSX looks interesting -- nice desktop for the
> illiterate, unix underneath for us nerds .. :)

OSX has only select() and is limited to 1024 descriptors. So much for
Apple's plans to sell their overpriced boxes in the server market.
But companies buying these are probably going to use Java and will have
other things to worry about first. :-)

> > TerminateThread causes the thread to exit unexpectedly. The thread then
> > has no chance to execute any user-mode code and its initial stack in not
> > deallocated.
> 
> This can probably be fixed
> [...]
> I wonder what Cygwin does ..?

You don't want to know. Really.

Bye,
     Mike