libuv integration

[DemiMarie]

We can provide a cross-platform, high performance, and fully asynchronous I/O library by integrating libuv with libui. This should be optional, but will be very useful for Node.JS, .NET Core, and other consumers.

On systems where we use GTK, we can poll on the libuv file descriptor. On macOS, we can poll on both the libuv file descriptor and the Core Foundation Mach port, and on Windows 10 we can add the IOCP to MsgWaitForSingleObject. On Windows 7 and Windows 8.1, we will need to use a separate thread.

If we would rather avoid undocumented behavior, we can just use a separate thread on Windows and macOS, but I would prefer the higher-performance solution.

[mischnic]

@parro-it

[parro-it]

We can provide a cross-platform, high performance, and fully asynchronous I/O library by integrating libuv with libui. This should be optional, but will be very useful for Node.JS, .NET Core, and other consumers

This was already discussed in the past. If I correctly remember, @andlabs didn't want to integrate it, in order to keep libui focused just on UI stuff. Anyway, we already implemented integration between the two event loops for the node.js bindings. You can see the last version sources here: https://github.com/parro-it/libui-napi/blob/master/src/event_loop.c

[mischnic]

Previous issues: https://github.com/andlabs/libui/issues/323 (opened by yourself), https://github.com/andlabs/libui/issues/146

[parro-it]

Regarding the technicalities...

This should be optional, but will be very useful for Node.JS, .NET Core, and other consumers.

Well, our implementation, as it stands, is specific for node.js, but I think some part of it could be easily abstracted to be generic on libuv .

[parro-it]

On systems where we use GTK, we can poll on the libuv file descriptor. On macOS, we can poll on both the libuv file descriptor and the Core Foundation Mach port, and on Windows 10 we can add the IOCP to MsgWaitForSingleObject. On Windows 7 and Windows 8.1, we will need to use a separate thread.

Unfortunately, this does not works, because Windows and macOS (only on last versions) don't allow you to wait on the mach port / to check for UI events from a background thread. So, what we do instead, is having a background thread where we wait on libuv background fd. When there is a libuv event pending, we create a GUI event and post it to the main thread.

This event will wake up the main thread (that is waiting for GUI event, and it allow it to process pendings libuv callbacks. This has some performance drawback because there is a GUI event processed for every libuv event, but I's the only working solution I found. The performance it's acceptable anyway.

[parro-it]

Ops, @DemiMarie we already had this discussion...

[cody271]

:+1:

Might not make sense to bring libuv in as a core dependency to libui .. Perhaps we'd need an optional libui-uvloop library or something. Regardless both libraries are still philosophically a perfect match for each other!

[parro-it]

Might not make sense to bring libuv in as a core dependency to libui

I agree, there is great value in remaining focused...

[parro-it]

Perhaps we'd need an optional libui-uvloop library or something. Regardless both libraries are still philosophically a perfect match for each other!

I'll investigate further if this is really easy to do using actual libui-node sources...

[rubyFeedback]

I think the problem is that the more you integrate into libui, even if it is only optional, still may add maintenance cost. Perhaps a cleaner way could be to just provide some plugin-infrastructure that is as flexible as possible. That way people could add plugins that may modify libui, without libui necessarily having to carry too much code specifically for just one plugin or another. A bit similar to python pypy (or whatever the store name was), perl cpan, ruby gems and so forth.

libui's main selling point is to provide a very simple UI-"layer" that is easy to distribute and use on different operating systems (in principle).