On Fri, Sep 16, 2011 at 10:20:10PM +0200, Petr Salinger wrote:
"true" sometimes exits too fast, "sleep 0.1" suffices.
Due to userspace implementation (via pthread_cond_timedwait),
/bin/true might end even before the signal is delivered.
BTW, I just verified, only kfreebsd-i386 is affected,
kfree
really needs a fractional second?) I'll also clone the bug over to libc
for a better fix, as I think it really needs to be handled there because
trying to work around the problem means making assumptions about the
implementation that I'm not sure are/will be valid.
I already thought about possib
Ah, now that makes sense. Kinda. It still doesn't explain why the result
is random. :-)
"true" sometimes exits too fast, "sleep 0.1" suffices.
Due to userspace implementation (via pthread_cond_timedwait),
/bin/true might end even before the signal is delivered.
BTW, I just verified, only kfreeb
On Fri, Sep 16, 2011 at 09:11:28PM +0200, Petr Salinger wrote:
fail on subsequent runs. Much smaller (order of magnitude) numbers seem
ok, and I haven't identified a specific bad number. In a loop, 8
seems ok, while 9 exhibits intermittant failure. Assuming that
holds true, we cou
fail on subsequent runs. Much smaller (order of magnitude) numbers seem
ok, and I haven't identified a specific bad number. In a loop, 8
seems ok, while 9 exhibits intermittant failure. Assuming that
holds true, we could set the max timeout to about 25 years (which should
suffice f
On Fri, Sep 16, 2011 at 07:24:41PM +0200, Petr Salinger wrote:
If any debian-bsd people could add some insight to this one, it would be
appreciated.
I've tried various test values, and it doesn't require the time be
exactly MAX_INT to fail (smaller values fail also).
Please which one ?
The 4
6 matches
Mail list logo
