[Ecls-list] libevent

[Juan Jose Garcia Ripoll]

On Fri, 2006-05-26 at 17:11 +0900, Brian Spilsbury wrote:
> What do people think about integrating libevent (conditionally) into
> the ecl core?

I have no problem with it. The source code of libevent should however be
distributed separately.

I have been reading the manpage of libevent and it seems to abstract
over different mechanisms (select, poll, kqueue) provided by the
operating systems to check existing input/output on a file descriptor.
Besides, it includes events which are timers.

What is not clear to me is what this library expects from the callback.
Does it have to perform some amount of non-blocking read/write? Can
these operations be interrupted by libevent?

> Another reason is that I'd like to get coroutine support happening
> sometime, and then have stream io integrated with scheduling, in which
> case all blocking operations would need to be scheduler-aware.

Why the interest in coroutines? Are native threads not a good option? If
so, then you might consider revisiting the old thread code in ECL. It
was user-based threads using alarm() IIRC.

An issue of coroutines vs. native threads is that one has to check for
the interruptibility of different functions. That is not so much a
problem with native threads because they are rarely interrupted (except
for some unix signals, but they typically denote something bad has
happened).

Regards,

Juanjo

-- 
Max-Planck-Institut für Quantenoptik
Hans-Kopfermann-Str. 1, Garching, D-85748, Germany
Phone: +49 89 32905 345   Fax: +49 89 32905 336
http://www.mpq.mpg.de/Theorygroup/CIRAC/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20060526/660cdabb/attachment.sig>