[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Idea for an event loop library
- From: Jay Carlson <nop@...>
- Date: Fri, 11 May 2012 01:20:00 -0400
On May 10, 2012, at 9:03 PM, Tim Caswell wrote:
> My only warning with making the non-blocking operations appear blocking is that it will bite novice programmers big time. Any function call into a third-party library will have the potential to suspend your current coroutine.
Any time you let control out of "your" code, where "your code" means all the stuff you understand.
> 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.
Let me underline that. Unless you know otherwise, any function invocation can pause; if you have made any assumptions about the state of the world, you need to re-establish those invariants after each call because it may have been a long time since the start of the call.
(Locking is one way of doing this--people can't mess with your head if to do so they need a lock you're holding.)
It's not that coroutines are a problem, it's that when you write in a callback style, programmers are used to acquiring resources and establishing preconditions at the beginning of functions. In coroutine style, you need to do that after any significant function call.
In the MOO language there were a couple of proposals batted around to cope with this. MOO is more syntaxy than Lua, so adding "atomic [...] end" made sense--any blocking operations inside would raise an error instead. I suppose Lua would use an xpcall analog.