| Age | Commit message (Collapse) | Author |
|---|
|
Jean-Christian de Rivaz writes:
The attached patch solve an issue I faced while using the libdbus-glib
waiting for a D-Bus message or the end of a glib timer at the same time.
This specific case of use generate a poll call with a zero timeout. On
platformes with the glibc a zero timeout poll return immetiately even if
there is no file descriptor event. But on platformes with uClibc a zero
timeout poll block until a file descriptor event occurs.
|
|
I actually suspect this code into the file uClibc/libc/sysdeps/linux/common/poll.c:
tval.tv_nsec = (timeout % 1000) *1000; <==== make only usec!
From milisecond this really needs a * 1000000 to make nanosecond. Without this
a 1100 milisecond timeout is converted into a 1 seconde and 100 microsecond
timeout! This can explain the weird result of the test code.
|
|
|
|
applications stop using _syscall#() and use syscall() instead. Cleanup
internal handling of syscall includes to use the correct header file.
|
|
|
|
|
|
missing headers, other jump relocs removed
|
|
|
|
|
|
|
|
|
|
is not a SuSv3 symbol). Rather than using __bzero internally per Alexandre's
original patch, use memset instead.
|
|
The #ifdef __NR_poll test was failing because it was done before any includes.
Hence, the emulation was always being used.
NOTE: The emulation fails a couple of tests in test_poll.py!
|
|
|
|
select for older 2.0 kernels where poll is missing.
|
