Re: [MirageOS-devel] Error handling in Mirage - request for comments!

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 30 Jan 2015, at 10:06, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> 
> On 30 January 2015 at 09:30, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> On 29 Jan 2015, at 15:24, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>> 
>>> As part of my continuing mission to break all Mirage APIs, I've
>>> written up some thoughts on how to improve error handling:
>> 
>> s/break/fix :-)
>> 
>>> 
>>> https://github.com/mirage/mirage-www/pull/274
>>> 
>>> Although written as if it's a final design, it's intended only as a
>>> starting point for discussion, to find out what we do and don't agree
>>> on. Please add comments, information about successful approaches
>>> you've seen, etc.
>> 
>> This is an excellent writeup.  My top-level view is that moving to
>> an exception-heavier model is fine, but that we really do need to adopt
>> some sort of Async-style monitor model to make this feasible, so that
>> exceptions can be contained within a logical section of the code.
> 
> Doesn't try_lwt (or similar) do this anyway? What particular problem
> are you worried about?
> 

It does, if used carefully everywhere -- and is quite slow.  The
problem is along the lines of:

Thread 1: try
Thread 1:   <code>
Thread 1:   Lwt.wakeup thread2
Thread 2:   <fast switch to thread2>
Thread 2:   raise Failure
Thread 1: catch 

The fast switch has caused thread 1 to catch the Failure.  With monitors,
there's always a monitor relevant to the active thread that is listening
for an exception on that thread.  It's a global variable so that thread
switching remains a fast operation,

> I don't have any experience with Async monitors beyond playing with
> them briefly yesterday after reading the RWO chapter on Async. But in
> this case Lwt seems to be using a clean, functional style, whereas
> Async is using global variables and hidden implicit state that is
> likely to lead to bugs such as the one I used in the example.
> 
> Though I may just be misunderstanding. Apart from that, Async seemed
> very sensible, and better than Lwt in places (e.g. always scheduling
> binds for later so they always run in the same context).

The tradeoff is definitely a performance one.  We could get roughly the
same behaviour with try_lwt applied everywhere, I suspect.

-anil

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel