Re: Merging libraries' main loops

[Jay Carlson <nop@...>]

On Mon, Nov 14, 2011 at 4:05 PM, Stefan Reich
<stefan.reich.maker.of.eye@googlemail.com> wrote:
> Here's a general question. Many Lua libraries define their own "master
> loop" that waits for events and processes them.

Many libraries, period. But "just call me from your idle function" is
so old it's new I guess.[1]

> Verse [meaning libstrophe]
> Copas

These wait for the next possible opportunity to read or write to
network streams. Their event loops ask to be blocked until one or more
sockets may have changed state.

Both include timer mechanisms for their own purposes, primarily
timeouts. So actually, it's "here are some sockets and the maximum
time I want to wait".

> IupLua

IupLua has an excuse: different platforms have dissimilar UI control
flow models. On Unix systems, most GUIs do bottom out in "wait for
something to happen on a set of file descriptors"; X exposes
XInternalConnectionNumbers(). So Copas and libstrophe and libXt could
all coexist. But if you're using a bigger GUI toolkit, especially one
aspiring to portability, it usually wins the "who owns the event loop"
fight. GTK provides a "notify me about these sockets" function for its
main loop.

In a POSIX readiness model, you want a function that waits for
"sockets OR widgets OR timer, whichever comes first". If that doesn't
exist, but time-limited waits for each of your event sources do, the
barbaric option of polling is available. If any event source has no
time-limited wait, you must use multiple threads or processes and
communicate between them.

As a portability note, select() does not *guarantee* I/O on sockets
marked ready cannot block (regardless of what your manpage may say) so
you probably want any network sockets you're working with to be set
nonblocking. [2]

> Question is: If I need two of these libraries at once, how do I
> combine their loops?

People seem to like libev. I don't know what would need to be done to
IUP though. (Nested event loops are fun; does a modal dialog box stop
network event processing as well?)

> There should be a general solution for this IMHO.

On POSIX systems, you should be able to ask a library for its list of
interesting fds and next timeout. Given this and "run one batch" it
would at least be possible to write a combined event loop.

Jay

[1]: I'm reminded of the system image in Squeak, which busy-waited and
polled for events; when this model did not do well on laptops, the
runtime was modified to detect when the image was doing no work except
pounding on "get next event"--the platform C code decided the image
had Had Enough, and started sleeping a bit on each poll. When the
image sobered up and started doing something, it was allowed to eat
battery again for a while. For all I know this was the right way to do
it on old MacOS, but it surely wasn't on my Linux framebuffer port.

Unfortunately, a lot of UI code was written with the model it would be
called on idle. Cleaning it up into closed-form waits for
timeouts/events looked daunting. I wonder if they did.

[2]: https://lkml.org/lkml/2011/6/19/160