hardens %ames initialization

[joemfb]

As discussed briefly in urbit/urbit#1236, %ames initialization is particularly fragile, and requires special accommodation by the runtime. This PR makes the handling of the ames process/boot event %barn more robust, at the expense of dropping (and therefore subsequently retrying) packets sent during the boot sequence.

[joemfb]

Note: this PR is to %ames as #1130 was to %behn

[joemfb]

/cc @philipcmonk, curious if you think this is a sufficient :aqua setup for now.

[philipcmonk]

I don't like switching to just doing a "hi" test. In particular, I would like to make sure that children can boot -- that sort of thing breaks often, and it tests things like filesystem sync.

Do you know why it failed the previous time? It looks a little suspicious because one of the checks passed and the other failed, but I think they both run aqua. The one that failed hung on the last test, %child-sync, which boots a parent and child, then changes a file on the parent and checks to see if the file changed on the child.

If this suggests a non-determinism in the tests, then it might be worth squashing that. Perhaps a more deterministic view of time (ie a fully virtualized time) would solve it.

[joemfb]

Since we added :aqua to the CI tests, it looks like "push" CI builds succeed and "pr" builds fail. I've double checked the CI config, but I don't see anything that's branching off of this condition.

I started fiddling with it here because I wanted to be sure I hadn't broken something. This change should only make %ames more robust during boot, but that's the kind of thing that can only be verified empirically (at least for now).

Do you think the tests should be augmented with timers to detect hangs?

[philipcmonk]

It's hard to generally determine when a test is hanging, since a ship will generally keep doing stuff forever (eg heartbeat its parent).  A wall clock timer would be reasonable.  I think the end solution is to fully virtualize time so that it runs everything as fast as possible and with the same timestamps each time.  Then, when defining a test give a certain amount of virtual time, eg "this should finish in 5 virtual minutes", and then fail it if it hasn't. We do need a way to use non-virtualized time, though, for interactively creating tests.  But I think it's sufficient to make that a toggle in the behn driver.

…

On Fri, Apr 12, 2019 at 8:55 AM, Joe Bryan < ***@***.*** > wrote: Since we added :aqua to the CI tests, it looks like "push" CI builds succeed and "pr" builds fail. I've double checked the CI config, but I don't see anything that's branching off of this condition. I started fiddling with it here because I wanted to be sure I hadn't broken something. This change should only make %ames more robust during boot, but that's the kind of thing that can only be verified empirically (at least for now). Do you think the tests should be augmented with timers to detect hangs? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub ( #1138 (comment) ) , or mute the thread ( https://github.com/notifications/unsubscribe-auth/AFS8GMTBZF954hfYIrj8YO_uD0lB8vQyks5vgKx7gaJpZM4crIV4 ).

[belisarius222]

oof good question

I suspect we should make a specific constant duct whose sole purpose is this Ames-Behn interaction.
~[/ames-behn] might be ok. I think we'd want it not to have a // at the front, to disambiguate it from ducts that have Unix origins.

If we do change that, though, I think we should do it in a different PR so we can git-bisect later if we need to.

[belisarius222]

LGTM

[belisarius222]

At some point, I'd really like to unify %barn and %born into one event. Doesn't need to happen now, though.