Re: Options for Asynchronous Callbacks

[steve donovan <steve.j.donovan@...>]

On Tue, Mar 27, 2012 at 5:40 PM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> Multithreading is hard, as Barbie the Software Engineer says ....

So a wise engineer avoids it .. I have restored sanity by abandoning
the 'async' part and only allowing callbacks to happen if either we're
sleeping or waiting for processes to finish.  This is not too
restrictive - one can always do everything in callbacks, remembering
not to hog the thread and doing heavy stuff in background processes -
which is very much the luvit philosophy, except in a 45K DLL that can
be used by regular Lua.

This can still play nice with GUI applications since then winapi
dispatches callbacks to a message window and calls them on the main
GUI thread. (and GUI applications are all about callbacks)

But playing nice with something like LuaSocket is hard, for the
reasons Thijs mentions - you have to get everyone to respect your
locks. The temptation is then to make a lockable version of the basic
LuaSocket TCP/IP core and still be able to reuse the rest of its
machinery. You then get Copas-like functionality without the
quick-timeout hacks.

Portability? Well, this was always intended as a Windows library; true
portability is anyway hard because even when Windows looks like POSIX,
it's doing it differently - for instance, you can actually throw a C++
exception from a signal handler.  Besides, Windows doesn't always get
the developer love it needs ;)

steve d.