Messages in this thread | | | Date | Tue, 17 Oct 2006 14:42:43 +0400 | From | Evgeniy Polyakov <> | Subject | Re: [take19 1/4] kevent: Core files. |
| |
On Tue, Oct 17, 2006 at 12:59:47AM -0500, Chase Venters (chase.venters@clientec.com) wrote: > On Tuesday 17 October 2006 00:09, Johann Borck wrote: > > Regarding mukevent I'm thinking of a event-type specific struct, that is > > filled by the originating code, and placed into a per-event-type ring > > buffer (which requires modification of kevent_wait). > > I'd personally worry about an implementation that used a per-event-type ring > buffer, because you're still left having to hack around starvation issues in > user-space. It is of course possible under the current model for anyone who > wants per-event-type ring buffers to have them - just make separate kevent > sets. > > I haven't thought this through all the way yet, but why not have variable > length event structures and have the kernel fill in a "next" pointer in each > one? This could even be used to keep backwards binary compatibility while
Why do we want variable size structures in mmap ring buffer?
> adding additional fields to the structures over time, though no space would > be wasted on modern programs. You still end up with a question of what to do > in case of overflow, but I'm thinking the thing to do in that case might be > to start pushing overflow events onto a linked list which can be written back > into the ring buffer when space becomes available. The appropriate behavior > would be to throw new events on the linked list if the linked list had any > events, so that things are delivered in order, but write to the mapped buffer > directly otherwise.
I think in a similar way. Kevent actually do not require such list, since it has already queue of the ready events.
-- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |