Re: New Event API for Luasocket

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

Hi,

Steven Elkins wrote:
> Your document mentions one other source, signals, and says the feature
> is "...probably much wanted."  I want it.  :-)

Well, there are tons of race conditions lurking there. Whatever I come up
with would be good enough for ctrl-c, kill -HUP and that kind of stuff.
But it will probably not be good enough for realtime signals or if you
rely on counting them.

Signal events will get delivered synchronously through the event iterator,
which may take some time to propagate. If that is not good enough I may
have to add event priorities ... oh please, no! Maybe a 'high-priority'
signal event type that just pulls ahead of the event queue is sufficient.

It would be helpful if you describe the way you want to use signals
in your application. Then I'll see what I can come up with.

> I'm also hoping for all manner of file descriptors.

If the object you are passing to the r/w/x event types has a gethandle()
method then you are all set. If not, then just wrap it up in a table,
add a gethandle() function and pass it as an event source.

I may add a shortcut that avoids the indirection via method resolution
for sockets (but this is performance tuning ... later).

So for POSIX environments all is fine and dandy. But I still need feedback
on the situation for Windows with all these different kinds of handles
(sockets vs. kernel vs. C runtime). I'm royally confused by the stuff
I've read over at MSDN. I bet someone else will step in and educate me.

> I suppose you've already looked at libevent (wrapped by LuaSys) and/or
> twisted (the python framework) for inspiration.

Yes I did. And there's liboop and Medusa. ACE and POE have been mentioned
on the list, too. And I've come across two dozen event loops in various
network servers and GUI libraries. I think I saw it first in BIND around
ca. 1988. I have to confess: I've written too many of this kind of loops
myself. Mostly for POSIX environments, though.

> Anyway, I'm very excited to learn of your plans.  I write IP traffic
> applications at work and I'm keenly interested in scriptable state
> machines.

This reaffirms my intuition that a passive event API is the only way
to really make everyone happy. While I'm leaning towards a coroutine-based
dispatcher on top of that (for scriptable heavy-duty network servers),
you may be better off with a state machine based dispatcher.

I hope we'll see a growing codebase that uses the event API so everyone
can pick the solution he/she likes most.

> I hope gmail wraps these longs lines.  If not, I apologize.

It does. The Google guys are smart. :-)

Anyway, thank you for your feedback!

Bye,
     Mike