guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on ‘wip-nio’


From: Neil Jerram
Subject: Re: Comments on ‘wip-nio’
Date: Thu, 22 Mar 2012 21:36:31 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> Hi,
>
> Nala Ginrut <address@hidden> skribis:
>
>> On Thu, Mar 22, 2012 at 6:39 AM, Ludovic Courtès <address@hidden> wrote:
>>
>>> Hello,
>>>
>>> I had a quick look at ‘wip-nio’, and here are initial comments.
>>>
>>>  • epoll is Linux-specific.  Any idea how a more multi-platform API
>>>    could be provided?  I guess libevent could be used, but we don’t
>>>    want to add one more dependency in 2.0.  How much is (ice-9 nio)
>>>    dependent on epoll vs. poll, for instance?
>>>
>>>
>> Maybe add a module named "(ice-9 linux)"? And we may add more
>> Linux-specific things.
>
> I’d rather have (ice-9 event) or such, and do our best to provide a
> portable implementation of the feature.

Here's another thought on requirements that might feed into that kind of
support.

I've recently been doing some UI programming, that also 
involves D-Bus.  Now the UI is Enlightenment, so my program's main loop
is the Enlightenment main loop (ecore_main_loop_begin).  But if the UI
used Gtk instead, then obviously the main loop would be gtk_main_loop.

Now consider another module that's mostly dealing with a D-Bus API.
This module has situations where it wants to implement "try calling this
API again in 10 seconds time" (possibly sadly, because it shouldn't have
to poll; but let's say that it does anyway).  How does it do that, while
integrating with the main loop of whatever programs might be using that
module?

It seems like the module has to anticipate the main loop infrastructure
that any using programs will use - which isn't a nice solution.

Having written this, I've realised that in the D-Bus case the module is
actually constrained already, because the concept of being able to
receive a D-Bus signal already implies integration with some kind of
main loop infrastructure.  In my case that's GDBus/GIO/glib, and the
integration with the Enlightenment UI is handled by calling
ecore_main_loop_glib_integrate; but I would guess that there are cases
where a module isn't already constrained like this, and still might want
to use a "do X in N seconds time" function.

Regards,
        Neil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]