In article <[EMAIL PROTECTED]> you wrote:
>> Now, as I understand, userspace threads in FreeBSD are preemptive.
>> So, though my 11 threads are all computational and do not do
>> any syscalls, sleeps, sched_yield, whatever -- newertheless,
>> the program should not be stuck in one thread. And it seems to
>> be sometimes true. But only sometimes!
>>
>> Depending on the phase of the moon (it seems) sometimes my
>> program gives (after ^C):
>>
>> ^C
>> Thread 0x00: 0
>> Thread 0x01: 0
>> Thread 0x02: 0
>> Thread 0x03: 0
>> Thread 0x04: 0
>> Thread 0x05: 0
>> Thread 0x06: 0
>> Thread 0x07: 0
>> Thread 0x08: 0
>> Thread 0x09: 0
>> Thread 0x0a: 488133092
> Hmm, I can't get this to occur with your test program. I've tried
> it several times and the threads seem to be scheduled properly.
> If you figure out how to repeat this without relying on phases of
> the moon, I'd be interested in hearing how.
That's what makes it most wierd for me -- I am not able to determine
conditions when it gives a "wrong" result. I'll keep trying though.
I also could probably compile libc_r with debug info and set a
breakpoint somewhere in threads scheduler to see what's going on.
Or, because it is time-related, it is not a good idea? Then
printfs in libc_r -- will they work? Could you suggest a good
place to start looking?
As I said, it seems to go in periods -- for some time everything
is normal, and then for some time -- bullshit :-\ You may try to
repeat it after some time. It may also be hardware dependent (?)
> Are you running NTP or changing the time?
That idea also came to me, but no -- I don't have NTP, and I don't
change the time. And as I said, the interrupts seem to keep being
delivered to the process.
> Dan Eischen
> [EMAIL PROTECTED]
---
After living in New York, you trust nobody,
but you believe everything. Just in case.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
