Xen project Mailing List

On Wed, Mar 26, 2014 at 10:20 AM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

On 26 Mar 2014, at 09:34, Dave Scott <Dave.Scott@xxxxxxxxxx> wrote:

>
>
>> On Mar 26, 2014, at 9:02 AM, "Richard Mortier" <Richard.Mortier@xxxxxxxxxxxxxxxx> wrote:
>>
>>
>>> On 25 Mar 2014, at 22:49, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>>
>>> One quick trick that often helps in these sorts of situations is to wrap the offending code in a try/with and print the backtrace:
>>>
>>> try
>>> the_bad_code
>>> with exn ->
>>> Printf.printf "Exn: %s\n%!" (Printexc.to_string exn);
>>> Printexc.print_backtrace stdout;
>>> raise exn
>>
>> didn't i add something like this to the pre-refactoring mirage at some point? did it get lost, or is it not possible to have now after all the refactoring? seems like dropping this to console before bailing out would be a useful default behaviour... should i add to the mirage cli tool maybe so that main.ml is generated appropriately?
>>
>
> Not sure about your change specifically, but my usual problem with a global try/with is that Lwt threads get in the way-- you end up with a boring stack with Lwt_main.run (ie the scheduler) on it and a frame for the current thunk you're running, without much clue as to how you got there. I'm not sure what the best fix for this would be -- possibly copying some ideas from core async?

The Async way is to maintain a monitor (very similar to an Erlang process monitor) that keeps an eye on a group of threads. The Async scheduler is thus responsible for keeping track of backtraces.

We're pretty close to being able to use Async in Mirage, but not quite yet. The critical path is:

- Core was split into Core_kernel and Core_unix, so we need to add the (very small) set of C stubs to support Core_kernel

I'll have to look at this first one relatively soon since I've added irminsule support to xenstore, irminsule uses Core_kernel and I really want to resurrect xenstore mirage stub domain support...

- Async_kernel now exists, so we need to link that in and test it under Xen
- Async_unix needs to be rewritten entirely for a Unix-free world, just as we did for Lwt. This is probably a week of expert work to get a prototype running, more to upstream.

To learn more about monitors:
https://realworldocaml.org/v1/en/html/concurrent-programming-with-async.html#exception-handling

Thanks for the pointer!

Cheers,

Dave

-anil

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

--
Dave Scott

Re: [MirageOS-devel] contributing best practices?