3 ms·
Well, just as there is the problem of thread-safety, there is also the problem of co-routine safety. Basically callbacks and coroutines don't play well togethe
by felixge2 16y ago
Well, just as there is the problem of thread-safety, there is also the problem of co-routine safety.
Basically callbacks and coroutines don't play well together.
But there were a bunch of reasons for the removal, performance and quality of the initial implementation also played into it AFAIK.
- kevingadd 16y agoIf you implement coroutines as a state machine they integrate just fine with callback-oriented APIs. But perhaps that was the problem since the PDF mentions stack swapping.
- jules 16y ago> Basically callbacks and coroutines don't play well together. Can you elaborate on this? I thought the opposite: coroutines play very well with callbacks. Callback libraries force you to write programs in continuation passing style. Coroutines let you write asynchronous programs in normal style. Lets assume we have an asynchronous readAsync(callback) function that reads a number and calls the callback with the input when it's ready. Now you're writing your program like this: readAsync(function(x){ readAsync(function(y){ write(x+y) }) }) What you want to write is this: x = read() // may block this coroutine, but *not* the entire program y = read() write(x+y) This can be achieved with something like: function read(){ coro = getCurrentCoroutine() var result callback = function(x){ result = x; coro.resume() } readAsync(callback) yield // stops the current coroutine until it is resumed return result } It seems to me that this is a general way to adapt any callback style library to coroutines.