On Mon, 20 Nov 2006 11:51:59 +0300
Evgeniy Polyakov <[email protected]> wrote:
> On Mon, Nov 20, 2006 at 12:43:01AM -0800, Andrew Morton ([email protected]) wrote:
> > > > >If thread calls kevent_wait() it means it has processed previous entries,
> > > > >one can call kevent_wait() with $num parameter as zero, which
> > > > >means that thread does not want any new events, so nothing will be
> > > > >copied.
> > > >
> > > > This doesn't solve the problem. You could only request new events when
> > > > all previously reported events are processed. Plus: how do you report
> > > > events if the you don't allow get_event pass them on?
> > >
> > > Userspace should itself maintain order and possibility to get event in
> > > this implementation, kernel just returns events which were requested.
> >
> > That would mean that in a multithreaded application (or multi-processes
> > sharing the same MAP_SHARED ringbuffer), all threads/processes will be
> > slowed down to wait for the slowest one.
>
> Not at all - all other threads can call kevent_get_events() with theirs
> own place in the ring buffer, so while one of them is processing an
> entry, others can fill next entries.
eh? That's not a ringbuffer, and it sounds awfully complex.
I don't know if this (new?) proposal resolves the
events-gets-lost-due-to-thread-cancellation problem? Would need to see
considerably more detail.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
