Re: [patch 2/4] new timerfd API v2 - new timerfd API

2007-09-26 Thread Michael Kerrisk
Davide Libenzi wrote: > On Tue, 25 Sep 2007, Jonathan Corbet wrote: > >> One quick question: >> >>> Like the previous timerfd API implementation, read(2) and poll(2) are >>> supported >>> (with the same interface). >> Looking at that interface, it appears that a process doing a read() on a >>

Re: [patch 2/4] new timerfd API v2 - new timerfd API

2007-09-26 Thread Michael Kerrisk
Davide Libenzi wrote: On Tue, 25 Sep 2007, Jonathan Corbet wrote: One quick question: Like the previous timerfd API implementation, read(2) and poll(2) are supported (with the same interface). Looking at that interface, it appears that a process doing a read() on a timerfd with no

Re: [patch 2/4] new timerfd API v2 - new timerfd API

2007-09-25 Thread Davide Libenzi
On Tue, 25 Sep 2007, Jonathan Corbet wrote: > One quick question: > > > Like the previous timerfd API implementation, read(2) and poll(2) are > > supported > > (with the same interface). > > Looking at that interface, it appears that a process doing a read() on a > timerfd with no timer set

Re: [patch 2/4] new timerfd API v2 - new timerfd API

2007-09-25 Thread Jonathan Corbet
One quick question: > Like the previous timerfd API implementation, read(2) and poll(2) are > supported > (with the same interface). Looking at that interface, it appears that a process doing a read() on a timerfd with no timer set will block for a very long time. It's an obvious "don't do

Re: [patch 2/4] new timerfd API v2 - new timerfd API

2007-09-25 Thread Jonathan Corbet
One quick question: Like the previous timerfd API implementation, read(2) and poll(2) are supported (with the same interface). Looking at that interface, it appears that a process doing a read() on a timerfd with no timer set will block for a very long time. It's an obvious don't do that

Re: [patch 2/4] new timerfd API v2 - new timerfd API

2007-09-25 Thread Davide Libenzi
On Tue, 25 Sep 2007, Jonathan Corbet wrote: One quick question: Like the previous timerfd API implementation, read(2) and poll(2) are supported (with the same interface). Looking at that interface, it appears that a process doing a read() on a timerfd with no timer set will block

Re: [patch 2/4] new timerfd API v2 - new timerfd API

2007-09-24 Thread roel
Davide Libenzi wrote: > This is the new timerfd API as it is implemented by the following patch: > > int timerfd_create(int clockid); > int timerfd_settime(int ufd, int flags, > const struct itimerspec *utmr, > struct itimerspec *otmr); > int

[patch 2/4] new timerfd API v2 - new timerfd API

2007-09-24 Thread Davide Libenzi
This is the new timerfd API as it is implemented by the following patch: int timerfd_create(int clockid); int timerfd_settime(int ufd, int flags, const struct itimerspec *utmr, struct itimerspec *otmr); int timerfd_gettime(int ufd, struct itimerspec *otmr);

[patch 2/4] new timerfd API v2 - new timerfd API

2007-09-24 Thread Davide Libenzi
This is the new timerfd API as it is implemented by the following patch: int timerfd_create(int clockid); int timerfd_settime(int ufd, int flags, const struct itimerspec *utmr, struct itimerspec *otmr); int timerfd_gettime(int ufd, struct itimerspec *otmr);

Re: [patch 2/4] new timerfd API v2 - new timerfd API

2007-09-24 Thread roel
Davide Libenzi wrote: This is the new timerfd API as it is implemented by the following patch: int timerfd_create(int clockid); int timerfd_settime(int ufd, int flags, const struct itimerspec *utmr, struct itimerspec *otmr); int timerfd_gettime(int ufd,