Chris Marusich <[email protected]> skribis:
> [email protected] (Ludovic Courtès) writes:
>
>> Chris Marusich <[email protected]> skribis:
>>
>>> Why does it pass? The (sleep 999999) form appears to be totally
>>> ignored, and I don't understand why. It's concerning to me that I can't
>>> understand how the code is being executed. I expected the test to hang.
>>
>> According to the manual (info "(guile) Signals"):
>>
>> -- Scheme Procedure: sleep secs
>> -- Scheme Procedure: usleep usecs
>> -- C Function: scm_sleep (secs)
>> -- C Function: scm_usleep (usecs)
>> Wait the given period SECS seconds or USECS microseconds (both
>> integers). If a signal arrives the wait stops and the return value
>> is the time remaining, in seconds or microseconds respectively. If
>> the period elapses with no signal the return is zero.
>>
>> So I suspect that the marionette process got a signal, and thus ‘sleep’
>> returned quickly. Could you print its return value?
>
> Thank you for the reply! The return value is 999998. Like you said,
> maybe it's possible that the marionette process got a signal. But why
> would that happen?
I’m not sure! It could be SIGPIPE or SIGCHLD, this is left as an
exercise to you. :-) Seriously, you could register signal handlers and
try to see what’s going on.
It doesn’t change the fact that the return value of ‘sleep’ must be
checked, though.
> I have a related question. Is there a guarantee that the test case will
> begin after the TOR service has started up?
Most service tests start by waiting for the service to be up using
something like:
(marionette-eval
'(begin
(use-modules (gnu services herd))
(start-service 'mcron))
marionette)
That blocks until ‘mcron’ is up or it has failed to start.
HTH!
Ludo’.
