RFC: libverto nearing release

[Nathaniel McCallum]

On Thu, 2011-06-30 at 23:05 -0400, Greg Hudson wrote:
> It seems dangerous to promise that a library can create a private event
> loop that will use the same implementation as the application's event
> loop, even when the application is not aware of libverto.  This seems
> difficult to deliver because:

This is not what verto_new() and verto_default() promise. All they
promise is that *an* implementation will be returned and that when
possible we should save memory by not linking in a new library. There is
no promise that the implementation is the "correct" one. To assure this,
you need to call verto_convert_NAME().

> 1. Testing whether you're linked to a particular library seems
> questionably portable.

Seeing that we are using a standard symbol resolution with dlsym() this
should be portable enough. I've used this technique in other projects
and the only place I've ever seen it fail is if a library is linked in
via dlopen() with the RTLD_LOCAL flag. I'm not aware of any OS which,
when doing standard dynamic linking, does not make the symbols available
for dlsym() (including win32 btw). In short, this technique should work
everywhere that matters.

> 2. The application may be using an event loop which libverto isn't aware
> of.

Use verto_convert_NAME().

> 3. The application may be using a private event loop implementation
> which libverto can't possibly be aware of.

Use verto_convert_funcs().

> If the application is aware of libverto, it can use verto_set_default()
> (although I'm not sure whether the current interface allows an
> application to set the default to a private event loop implementation;
> I'd have to check that).

No, verto_set_default cannot currently use a private event loop
implementation.

Nathaniel