Also, the main reason we historically haven't supported regular sleep() is because of the expectation to be woken up by a signal if one is sent. We probably have all of the pieces to make this work at this point, but we haven't put it together yet. Mostly because it would involve aborting a syscall (which shouldn't be a problem, we just have to wiggle out the details still).
On Wed, Nov 11, 2015 at 5:47 PM, Kevin Klues <[email protected]> wrote: > Glibc's sleep() call is non-functional at the moment (it calls > __nanosleep() under the hood, which is stubbed out still). Until we > fix that, you can get a thread to sleep by calling uthread_sleep(). > That call issues sys_block() under the hood, which does a NULL syscall > that takes X number of microseconds to complete. Per our normal async > syscall path, the thread is then blocked in user-space for the > duration of the call. > > On Wed, Nov 11, 2015 at 5:36 PM, 'Davide Libenzi' via Akaros > <[email protected]> wrote: >> It looks like sleep(3) suffer insomnia and never sleeps >> Or Akaros does not play well with KVM as far as clock/timers goes (strange >> though, because LAPIC timers work fine). >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Akaros" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > > > -- > ~Kevin -- ~Kevin -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
