|
From: Kenton V. <tem...@ga...> - 2003-08-22 23:36:14
|
>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 |