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

[Thomas Leonard <talex5@xxxxxxxxx>]

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?

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).

> I think that making an Lwt_monitor only needs a minor patch to the
> engine -- on a context switch, the thread's current monitor needs
> to be set into a global variable so that the toplevel try/catch can
> route it.  It may be possible to do this without a patch and purely
> with the thread-local map.


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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