[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Idea for an event loop library
- From: Mark Hamburg <mhamburg.ml@...>
- Date: Sat, 12 May 2012 09:22:30 -0700
On May 12, 2012, at 9:03 AM, Mark Hamburg <mhamburg.ml@gmail.com> wrote:
> Lightroom uses a coroutine system that allows yielding from anywhere (well, modulo pcall limitations).[*] Mostly this works well, but there have been times where bugs have come up because the state of the world changed out from under some code that didn't think about the fact that the operation being invoked — even though it was clearly a long running operation — could yield.
>
> Revel doesn't use coroutines. It's approach could be described as a mixture of node.js with Flapjax where the reactive model allows us to avoid drowning the control flow in explicit callbacks. That said, I have been thinking about adding some support for coroutines in order to make it easier to write "try A, if that fails, try B" and such like.
[*] This is a "fun" piece of code to write if you want to leave coroutines working for other cases. You basically need to patch resume and yield to recognize and pass magic cookies to decide how far up the resume chain to yield.
[**] Lightroom 1.0 bug example. Tell Lightroom to update the on disk metadata for a bunch of photos. Then tell Lightroom to delete those photos from its catalog. The low-level code yields while updating the metadata, comes back and wants to mark the ORM object for the photo to record this fact, and runs into the fact that the corresponding record has been deleted. The app actually survives for a variety of reasons, but none of those reasons are pretty.