On 10/27/2012 05:52 AM, Matt Helsley wrote:
> On Thu, Oct 25, 2012 at 12:23:24PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Pat,
>>
>>
I suppose that I have a concern that goes in the other direction. Is
there not some other solution possible that doesn't require the use of
On 10/27/2012 05:52 AM, Matt Helsley wrote:
On Thu, Oct 25, 2012 at 12:23:24PM +0200, Michael Kerrisk (man-pages) wrote:
Hi Pat,
I suppose that I have a concern that goes in the other direction. Is
there not some other solution possible that doesn't require the use of
EPOLLONESHOT? It seems
On Thu, Oct 25, 2012 at 12:23:24PM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Pat,
>
>
> >> I suppose that I have a concern that goes in the other direction. Is
> >> there not some other solution possible that doesn't require the use of
> >> EPOLLONESHOT? It seems overly restrictive to
On Thu, Oct 25, 2012 at 12:23:24PM +0200, Michael Kerrisk (man-pages) wrote:
Hi Pat,
I suppose that I have a concern that goes in the other direction. Is
there not some other solution possible that doesn't require the use of
EPOLLONESHOT? It seems overly restrictive to require that the
On 10/23/12 12:15 PM, Andreas Jaeger wrote:
On 10/23/2012 07:23 PM, Paton J. Lewis wrote:
[Re-sending without HTML formatting; all vger.kernel.org destination
addresses bounced my original response.]
On 10/16/12 8:12 AM, Michael Kerrisk (man-pages) wrote:
[CC += linux-api@]
Thank you; is
On 10/25/12 3:23 AM, Michael Kerrisk (man-pages) wrote:
Hi Pat,
I suppose that I have a concern that goes in the other direction. Is
there not some other solution possible that doesn't require the use of
EPOLLONESHOT? It seems overly restrictive to require that the caller
must employ this
Hi Pat,
>> I suppose that I have a concern that goes in the other direction. Is
>> there not some other solution possible that doesn't require the use of
>> EPOLLONESHOT? It seems overly restrictive to require that the caller
>> must employ this flag, and imposes the burden that the caller must
Hi Pat,
I suppose that I have a concern that goes in the other direction. Is
there not some other solution possible that doesn't require the use of
EPOLLONESHOT? It seems overly restrictive to require that the caller
must employ this flag, and imposes the burden that the caller must
On 10/25/12 3:23 AM, Michael Kerrisk (man-pages) wrote:
Hi Pat,
I suppose that I have a concern that goes in the other direction. Is
there not some other solution possible that doesn't require the use of
EPOLLONESHOT? It seems overly restrictive to require that the caller
must employ this
On 10/23/12 12:15 PM, Andreas Jaeger wrote:
On 10/23/2012 07:23 PM, Paton J. Lewis wrote:
[Re-sending without HTML formatting; all vger.kernel.org destination
addresses bounced my original response.]
On 10/16/12 8:12 AM, Michael Kerrisk (man-pages) wrote:
[CC += linux-api@]
Thank you; is
On 10/23/12 6:26 AM, Michael Kerrisk (man-pages) wrote:
On 10/23/12 10:23 AM, Paton J. Lewis wrote:
[Re-sending without HTML formatting; all vger.kernel.org destination
addresses bounced my original response.]
On 10/16/12 8:12 AM, Michael Kerrisk (man-pages) wrote:
[CC += linux-api@]
Thank
On 10/23/2012 07:23 PM, Paton J. Lewis wrote:
[Re-sending without HTML formatting; all vger.kernel.org destination
addresses bounced my original response.]
On 10/16/12 8:12 AM, Michael Kerrisk (man-pages) wrote:
[CC += linux-api@]
Thank you; is this sufficient to coordinate the required
[Re-sending without HTML formatting; all vger.kernel.org destination
addresses bounced my original response.]
On 10/16/12 8:12 AM, Michael Kerrisk (man-pages) wrote:
[CC += linux-api@]
Thank you; is this sufficient to coordinate the required changes to the
glibc version of epoll.h?
Hello
Hello Paton,
PLEASE use a properly quoting mail client! It's very hard now for
third parties to see what I wrote versus your replies.
On Tue, Oct 23, 2012 at 1:06 AM, Paton J. Lewis wrote:
>
> On 10/16/12 8:12 AM, Michael Kerrisk (man-pages) wrote:
>
> [CC += linux-api@]
>
> Thank you; is this
Hello Paton,
PLEASE use a properly quoting mail client! It's very hard now for
third parties to see what I wrote versus your replies.
On Tue, Oct 23, 2012 at 1:06 AM, Paton J. Lewis pale...@adobe.com wrote:
On 10/16/12 8:12 AM, Michael Kerrisk (man-pages) wrote:
[CC += linux-api@]
Thank
[Re-sending without HTML formatting; all vger.kernel.org destination
addresses bounced my original response.]
On 10/16/12 8:12 AM, Michael Kerrisk (man-pages) wrote:
[CC += linux-api@]
Thank you; is this sufficient to coordinate the required changes to the
glibc version of epoll.h?
Hello
On 10/23/2012 07:23 PM, Paton J. Lewis wrote:
[Re-sending without HTML formatting; all vger.kernel.org destination
addresses bounced my original response.]
On 10/16/12 8:12 AM, Michael Kerrisk (man-pages) wrote:
[CC += linux-api@]
Thank you; is this sufficient to coordinate the required
On 10/23/12 6:26 AM, Michael Kerrisk (man-pages) wrote:
On 10/23/12 10:23 AM, Paton J. Lewis wrote:
[Re-sending without HTML formatting; all vger.kernel.org destination
addresses bounced my original response.]
On 10/16/12 8:12 AM, Michael Kerrisk (man-pages) wrote:
[CC += linux-api@]
Thank
Il 19/10/2012 15:29, Paul Holland ha scritto:
> A disadvantage of solutions in this direction, which was not preset in
> Paton's patch, is that all calls to epoll_wait would need to specify some
> timeout value (!= -1) to guarantee that they each come out of epoll_wait
> and execute the "pass the
On 10/19/12 6:03 AM, "Paolo Bonzini" wrote:
>Il 18/10/2012 20:05, Andy Lutomirski ha scritto:
>>
>> Unless something is rather buggy in kernel land (and I don't think it
>> is), once EPOLL_CTL_DEL has returned, no call to epoll_wait that starts
>> *after* EPOLL_CTL_DEL finishes will return that
Il 18/10/2012 20:05, Andy Lutomirski ha scritto:
>
> Unless something is rather buggy in kernel land (and I don't think it
> is), once EPOLL_CTL_DEL has returned, no call to epoll_wait that starts
> *after* EPOLL_CTL_DEL finishes will return that object. This suggests
> an RCU-like approach:
Il 18/10/2012 20:05, Andy Lutomirski ha scritto:
Unless something is rather buggy in kernel land (and I don't think it
is), once EPOLL_CTL_DEL has returned, no call to epoll_wait that starts
*after* EPOLL_CTL_DEL finishes will return that object. This suggests
an RCU-like approach: once
On 10/19/12 6:03 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 18/10/2012 20:05, Andy Lutomirski ha scritto:
Unless something is rather buggy in kernel land (and I don't think it
is), once EPOLL_CTL_DEL has returned, no call to epoll_wait that starts
*after* EPOLL_CTL_DEL finishes will
Il 19/10/2012 15:29, Paul Holland ha scritto:
A disadvantage of solutions in this direction, which was not preset in
Paton's patch, is that all calls to epoll_wait would need to specify some
timeout value (!= -1) to guarantee that they each come out of epoll_wait
and execute the pass the buck
[cc Paul McKenney, who is probably the leading expert on these things]
On 10/17/2012 04:30 PM, Andrew Morton wrote:
> On Tue, 16 Oct 2012 17:12:57 +0200
> "Michael Kerrisk (man-pages)" wrote:
>
>> On Thu, Aug 23, 2012 at 11:15 PM, Paton J. Lewis wrote:
>>> From: "Paton J. Lewis"
>>>
>>>
[cc Paul McKenney, who is probably the leading expert on these things]
On 10/17/2012 04:30 PM, Andrew Morton wrote:
On Tue, 16 Oct 2012 17:12:57 +0200
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote:
On Thu, Aug 23, 2012 at 11:15 PM, Paton J. Lewis pale...@adobe.com wrote:
From:
On Tue, 16 Oct 2012 17:12:57 +0200
"Michael Kerrisk (man-pages)" wrote:
> On Thu, Aug 23, 2012 at 11:15 PM, Paton J. Lewis wrote:
> > From: "Paton J. Lewis"
> >
> > Enhanced epoll_ctl to support EPOLL_CTL_DISABLE, which disables an epoll
> > item.
> > If epoll_ctl doesn't return -EBUSY in
On Tue, 16 Oct 2012 17:12:57 +0200
Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote:
On Thu, Aug 23, 2012 at 11:15 PM, Paton J. Lewis pale...@adobe.com wrote:
From: Paton J. Lewis pale...@adobe.com
Enhanced epoll_ctl to support EPOLL_CTL_DISABLE, which disables an epoll
item.
[CC += linux-api@]
Hello Paton,
On Thu, Aug 23, 2012 at 11:15 PM, Paton J. Lewis wrote:
> From: "Paton J. Lewis"
>
> Enhanced epoll_ctl to support EPOLL_CTL_DISABLE, which disables an epoll item.
> If epoll_ctl doesn't return -EBUSY in this case, it is then safe to delete the
> epoll item in a
[CC += linux-api@]
Hello Paton,
On Thu, Aug 23, 2012 at 11:15 PM, Paton J. Lewis pale...@adobe.com wrote:
From: Paton J. Lewis pale...@adobe.com
Enhanced epoll_ctl to support EPOLL_CTL_DISABLE, which disables an epoll item.
If epoll_ctl doesn't return -EBUSY in this case, it is then safe to
30 matches
Mail list logo
