Get some space between the IO driver and vane, since the driver is
mostly self-contained now and only depends on %khan for thread running.
"Conn" is a nautical term; it is the status of being in control of a
ship's movements, or the act of controlling a ship.
Before this, u3v_lily would erroneously accept atoms bigger than 64 bits
that, when truncated to 64 bits, were 31-bit numbers.
Decided to drop _cv_mole altogether. Another option would be to write a
u3r_chub_fit, write _cv_mole in terms of that, and check width in
u3v_lily as it currently does.
I tried to add a test case, but it seems that tests don't have access to
an ivory pill for +scot / +slaw. This would be the test case, more or
less:
{
c3_l lit_l;
c3_w big_w[] = {0, 0, 1};
u3_atom big = u3i_words(3, big_w);
u3_noun cod = u3dc("scot", c3__ux, big);
if ( c3y == u3v_lily(c3__ux, cod, &lit_l) ) {
printf("fail\n");
}
}
(The refcounting was also messed up, possibly from my refactor to use
+slaw instead of +slay, but this seems to have been unrelated.)
- Caught a couple potential leaks.
- Reworded error messages to be more @tas-compliant.
- Used unique error codes in bal_f calls.
- Moved u3z calls onto same line as returns.
Not sure we actually want to guarantee exactly-once response semantics,
so you can't rely on request ordering to correlate requests even if you
never send simultaneous requests.
Also do a worked example of a %urth scry, which hopefully raises the
question of whether %urth should try to support views.
It was if 0'd out in noun/vortex.c. That seems like a more reasonable
place to put it then a whole other self-contained file.
The commented version used slay instead of slaw and had an extra paren;
I opted to replace it with the impelementation from reck.c from http.c.
Inlines the server initialization in _khan_io_talk. Adds a van_o loobean
that differentiates between having the vane and missing the vane; van_o
is c3n if the %born event failed. In that case, we don't bother
forwarding %fyrd requests at all, but %peek requests still go through.
It was a mistake to call it except from _khan_close_chan, so just inline
it at the one call site. Also lets us stop doing our own pointer
juggling in _khan_io_exit.
While we're at it, flip argument order in _khan_close_chan;
superordinate first seems more natural.
- Have _khan_read_wire take a tag rather than produce it; if the tag is
not the one passed, it assumes it knows nothing of the rest of the
wire structure and simply returns c3n.
- rename _khan_search_chan to _khan_find_chan, the latter being more
flwy.
- Reformat %peek responses to start with request-id.
- Send %fyrd errors back over the channel that started the %fyrd.
- Factor out _khan_read_wire, reused by both _khan_poke_bail and
_khan_io_kick.
- Move _khan_search_chan up above _khan_poke_bail to use it there.
liv_o was always c3n without the vane. The pier was waiting for all
drivers to report liv_o == c3y. Tragedy ensued.
Maybe now we want to open the socket for peeks and moves even if the
vane is not present, so this may need to be rethought even further.
This is just the simple resolution for the culprit unearthed by
git-bisect.
Keeping a request list allows us to detect the case where a scry result
has returned on a connection that has already been closed, so we can
noop in that case.
Flipping the order of tag and request-id seems more natural for the
%fyrd case; otherwise there's no clear thing to send to the vane.
(Sending the whole jar sends request-id twice; once in the wire, once in
the body. Sending only the command itself loses context and introduces
potential namespace overlaps.)
As of now, scries are working.
And the format the IO driver takes is:
$: request-id=@ud
$% [%fyrd fyrd-args=*]
[%peek peek-args=*]
[%move move-args=*]
==
