Re: Idea for an event loop library

[Jorge <xxopxe@...>]

On jue, 2012-05-10 at 20:03 -0500, Tim Caswell wrote:
> My only warning with making the non-blocking operations appear
> blocking is that it will bite novice programmers big time.  

Very interesting comments (and others down the thread, too). I'm only
starting to play around with these concepts, and still don't actually
grasp the consequences. Also, my only experience with callback driven
programs was GUI stuff (as a novice programmer, no less) and I found I
very quickly got scared of my own code. Get distracted a split second
and there are those global variables sharing state between callbacks,
ugh.

> Any function call into a third-party library will have the potential
> to suspend your current coroutine.  
...
> With implicit suspensions you get into nasty issues similar to thread
> preemption where local state changes out from under you because some
> other event messed with your data.  

Ok, I see the problem. The motivation behind Lumen was to see how much i
can do in self-contained, Lua only library, so yes, perhaps I assume a
tighter control of the code than usual. It's just an experiment about
where to place complexity. And, for the only system i've developed using
it (a thing that moves data between files and sockets in various weird
ways) it has so far worked surprisingly well.

Here comes another murky line of reasoning. I was once surprised on how
closures Just Worked, and meant whatever was reasonable in a given
context, even when you as a programmer didn't fully understand the
implications. I wrote an object thing that held the attributes in
closures, without even thinking about it, just because the syntax seemed
natural. And only after that worked and was in production for a while, I
realized it was an object, and didn't have semicolons, etc. So perhaps
i'm just hoping that these data visibility problems will be magically
solved by closures, too :)

Jorge