alfred at freebsd.org
Thu Apr 27 12:47:09 UTC 2017
Can't something similar to this be done?
.(05:40:37)(bright at elvis.mu.org)
~ % mkfifo derp
.(05:43:46)(bright at elvis.mu.org)
~ % cat derp &
.(05:43:53)(bright at elvis.mu.org)
~ % ( pwait $! && echo "$?" > ex_status )&
.(05:44:28)(bright at elvis.mu.org)
~ % echo "hi" >> derp && echo "exit status: $(cat ex_status)"
 + done ( pwait $! && echo "$?" > ex_status; )
 + done cat derp
exit status: 0
Make a fifo, lodge a cat(1) process waiting for data, pwait in the background and stuff pwait's status into a file, then unstick the cat(1) by writing to the fifo, and then read the exit status from pwait from the file?
On 4/25/17 7:22 PM, Ngie Cooper wrote:
> On Tue, Apr 25, 2017 at 4:02 PM, Brooks Davis <brooks at freebsd.org> wrote:
>> I've been running the FreeBSD test suite for mips64 under qemu. As a
>> result, I'm seeing some tests fail due to assumptions about timing producing
>> test races. For example one of the pwait tests does this:
>> sleep 1 &
>> sleep 5 &
>> sleep 10 &
>> atf_check \
>> -o empty \
>> -e empty \
>> -s exit:124 \
>> timeout --preserve-status 7.5 pwait -t 6 $p1 $p5 $p10
>> Under emulation, particularly if the host disks are busy, it's easily
>> possible for the first sleep to exit before pwait actually runs.
>> In practice, we could probably get away with cranking up the times a
>> fair bit, but that would make the test slow and the race would still
>> Any thoughts about the right solution? Something not time based would
>> be ideal, but then it seems like we'd need a parallel process to kill
>> some of the waited for victims we quickly end up with something more
>> complicated than pwait that also needs testing...
> (Adding bdrewery@, testing@)
> I need to think about this a bit. The issue might be that we're using
> the wrong timer for sleep(1)/need to account for being interrupted.
> Needless to say, emulation really screws up timing assumptions because
> virtual clocks don't function like hardware clocks.
> freebsd-hackers at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
More information about the freebsd-testing