Re: [evlan-devel] event driven programming / exceptions

[Kenton V. <tem...@ga...>]

>I've pretty much read everything on the Evlan website,

Whoah!  Someone is actually paying attention to Evlan?  :)

>I've done quite a bit of event driven programming myself, in C, ObjC and 
>Python, and I've never seen a portable and efficient way around using the 
>select call for async programming with file descriptors.  How do you plan 
>to get around this limitation in Evlan?  Short of using a thread dedicated 
>to sitting on select(), or polling (using a short or no timeout on select, 
>if there is other processing to be done) I can't think of any way.

Many operating systems provide better methods of waiting on multiple events 
than select().  Unfortunately, every OS seems to be different.  In 
particular, Win32 has message queues, APC's, and I/O completion ports, 
while FreeBSD (and thus also OSX, I think) offers something called "kernel 
queues" (which are quite nice).  Supposedly Linux has very recently caught 
up and implemented an interface they call "/dev/epoll", though from what 
I've seen it's not very pretty.  In any case, the Evlan libraries will use 
the best method on each OS, abstracting it so that the programmer won't 
need to know the difference.  In cases where select() is the only option, 
the libs will just have to fall back on it (and servers on those OS's just 
won't be as scalable).

>How do you plan to support timed events (sleep for a while, call this 
>function later, etc.)?

Just like any other events...  The system will provide an interface to the 
timer which will allow for such things.

>What are your ideas for how the scheduler will work in Evlan, given that 
>today's processors are basically serial?

Usually, independent operations will just be performed in some arbitrary 
order.  However, if an event handler spends a particularly long time 
processing one event, a new thread could be created to process more events 
in the meantime.  I haven't really thought a lot about the details of this 
yet, as it will be quite a while before we get into implementing such things.

>Also I didn't see any mention of exceptions anywhere.  Do you plan to 
>implement exceptions, or something functionally equivalent to them?

I think that, for small-scale code, the predicate-based type stuff will 
make exceptions unnecessary in most cases.  That is, simple function calls 
won't have a whole lot of use for them.  However, I can see exceptions 
being a whole lot more useful at the message-passing level -- that is, it 
should be possible to send an exception back in response to a message.  The 
message passing stuff is, however, more of an API than a language feature, 
so exceptions don't need to exist in the core language to be used 
there.  Of course, the "process" dialect turns message-passing into more of 
a language feature, and so I would expect to integrate exceptions into that 
dialect.

Bleh.  The last paragraph was rather confusing.  Basically, while there 
aren't exceptions now, I have thought about them, and I am a fan of 
exceptions in C++.  I just want to experiment with the language more before 
I decide exactly where and how I want to integrate them.  Evlan will have 
some form of exceptions eventually.

-Kenton Varda