/dev/urandom doesn't working?

[kaliber]

I think, that cat /dev/urandom should produce some output but it doesn't.

DEBUGS:

random: open("urandom")

and after ctrl-c

random: close() random: free()

[korli]

Did you test on real hardware ? How much time did you wait before ctrl+c ?

[kaliber]

At least 10 seconds.

QEMU and VMWare.

[korli]

Could you wait a lot more with emulated systems ? urandom init is very cpu consuming. I experienced the same kind of behavior already.

[kaliber]

After 4 minutes first data occur. It's too slow... Maybe there is problem with scheduler because the CPU was mostly idle.

[axeld]

That actually happens because I changed the thread_yield() function - it now does a snooze(10000) which is obviously much too long for this kind of use. We could either wait for the new scheduler, or just use snooze() with a lower value in there again (like its BeOS version does).

[jackburton]

This doesnt' happen anymore, since axel changed urandom to do a snooze(100). urandom is still slow, but at least it doesn't wait 4 minutes before showing some output anymore. Shall we close this ? Or maybe let's keep it open but change the description to "urandom is slow" (see hrev23904)

[jackburton]

BTW for the yield issue... can't we modify thread_yield() to just remove the thread from the run queue and reinsert it back ? I tried to do just that, changed urandom to use yield() again, and now it's blazing fast.

[axeld]

That was similar to our original version of thread_yield() (I think it put it in the run queue as if would have priority 1). However, our allocator uses thread_yield() when it cannot get an internal lock (it would be not that easy to change it to use semaphores).

While that works fine usually, when there is a high priority thread waiting, no one else would ever have the chance to get that lock, because the high priority thread is constantly trying.

Maybe we should revert to that priority 1 version again - at least it should work better now, since the scheduler does not ignore lower priority threads that often anymore.

[bonefish]

Replying to axeld:

That was similar to our original version of thread_yield() (I think it put it in the run queue as if would have priority 1). However, our allocator uses thread_yield() when it cannot get an internal lock (it would be not that easy to change it to use semaphores).

While that works fine usually, when there is a high priority thread waiting, no one else would ever have the chance to get that lock, because the high priority thread is constantly trying.

You disabled thread_yield() in hrev21572 due to "ongoing problems". In hrev22515 you fixed a problem in the scheduler with skipping high priority threads. So the main reason might be fixed already, right?

At any rate, thread_yield() should be used sparingly in high priority threads anyway.

Maybe we should revert to that priority 1 version again - at least it should work better now, since the scheduler does not ignore lower priority threads that often anymore.

Since I'll need /dev/urandom to work fast now, so that building Perl doesn't take ages, I'll introduce a "force" boolean parameter to thread_yield() that when true, will use the current implementation and otherwise just call scheduler_reschedule() without priority adjustment or setting was_yielded, so that the thread will continue to run, if no other thread is ready. This should be perfect for the random driver's purpose.

[jackburton]

bonefish, did you forget to close this one by chance ?

[bonefish]

Works well enough since hrev23907.