Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
regression: exception End_of_file #39
while mirage-net-xen=1.4.1 ouputs:
mirage-net-xen=1.6.0 (and likely 1.5.0) outputs:
and kills the unikernel hard... to reproduce, this is a unikernel serving a HTTP website and force-reloading it from the browser...
I guess the error from 1.4.1 is coming from:
The corresponding code in 1.6.0 is:
Arguably, the new code is correct. An unhandled async exception from the application should be handled by the application's handler (Lwt default: crash with stack trace), not hard-coded as a print statement in mirage-net-xen.
On balance, I think it would be better to log these errors in tcpip. That can provide more context about the problem (e.g.
added a commit
May 4, 2016
my opinion on this is that the catch shouldn't be there... but in order to do that we should fix up all libraries up the stack which we have under control, then make releases (and at the same time, adjust [mirage-net-unix])https://github.com/mirage/mirage-net-unix/blob/ddb6d03893145309fa49f58a65298eb8c4fb1f24/lib/netif.ml#L126) to behave in the same way). since tcpip etc. do not directly depend on mirage-net-xen, I believe the safest is to use a mirage-types release for that (maybe the one where we switch to proper error handling?) [and related to the errors in https://github.com/mirage/mirage-net-xen/commit/6b1687c866eed9c23a239b2cdc7c32a4bc01bc33]...
I don't think changing types helps here. The listen callback isn't supposed to return an error, so the type is already correct.
The only choice is how to handle a bug in the callback function:
I'm happy with the behaviour in this PR.