Signal-based io questions

Marc Lehmann schmorp at schmorp.de
Fri Sep 11 15:58:48 CEST 2009


On Fri, Sep 11, 2009 at 02:42:47PM +0200, Zsbán Ambrus <ambrus at math.bme.hu> wrote:
> real-time signals to discover exactly what events happen.

You wish :)

> My first question is whether this third method could be the base of a

It would be possible to implement, but mostly pointless: the complexity is
enourmous, and the performance abysmal (as you have to flal back on select
etc. under load anyways). Portability is low, and it is not a good citizen
(processes have to fight for the signal, and there is no arbitration).

Libevent has had such a backend in the past, and apparently they made
practical experiences matching my theoretical claims above :)

> Secondly a seemingly unrelated topic.  Some interpreters, most
> importantly ruby 1.8 use a system where they use signals to implement
> switching between threads on time slices.

Yes, Coro under perl can do the same, (btw.).

> My second question is whether libev could be used in the scheduler of
> a system like this, to determine which threads to run?

Sure.

> Perl Coro can use libev to decide which coro to switch to, but it does
> not interrupt threads on a timer before they would block.

That's a feature that is easy to implement on the perl level however (the
manpage of Coro has an actual example of timeslicing, btw.).

Perl also has the advantage of being able to run libev asynchronously
and interrupt perl without a signal, purely in userspace (signals cost
thousands of cycles, not including any other kernel functions thta might
have to be used for this to work).

I would imagine that other scripting languages can do that, too (it's imho
rather costly to check a flag on every opcode or similar despatch, and
signal handling like that introduces unfixable races, but indeed, it is
the method of choice for many interpreters/vms, including perl).

> My third question is whether you could improve some of these threading
> systems by interrupting a running thread not only when its time slice
> runs out, but also when an external event (io or timer or anything
> else) makes another thread runnable?

Yes, run a separate event loop (in Perl, you cna run them e.g. via
EV::Loop::Async).

> This could be implemented by using the above mentioned F_SETOWN feature
> to request signals to be delivered on an io event (and similarly setting
> up alarm signals for the next timer event), and making these signals set
> that flag as well.

It could, but it would be very slow. Note you also need to write to a pipe
or something like that to wake up your select() or equivalent call when
your foreground program blocks in it (i.e. runs an event loop on its own).

> My fourth question applies only if the answer to the previous two is
> yes, namely whether in this case libev itself could arrange for the io
> and alarm signals to be sent on events the program is watching?

It could, but I don't think that makes any sense - about any other method
is more efficient and simpler to implement for the user, so I cannot
imagine that it would be actually useful for something.

Again, note that the signal is not enough unless you busy-wait in your
interpreter.

> way the program would have to register the event a thread is blocking
> on, and then libev would use this both to determine which thread can
> be ran next and to set the thread interrupt flag early.

libev knows nothing about threads, and should cetrianly not acquire
ruby-only fetaures, or thread-switching features, that are completely
outside of its scope.

It's indeed meant to be an event loop, and just that. For Perl, at least,
all the additional fucntionality is available (Async::Interrupt to
interrupt a running interpreter in a race-free way using flag, signals,
pipe/eventfd, EV::Loop::Async to run an event loop in a separate pthread).

Since it's in-use in Perl, I assume the proof of existance is available.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list