Re: [take25 1/6] kevent: Description.

[Evgeniy Polyakov]

On Thu, Nov 23, 2006 at 02:33:16PM -0800, Ulrich Drepper (drepper@xxxxxxxxxx) wrote:
> Evgeniy Polyakov wrote:
> >+ int kevent_commit(int ctl_fd, unsigned int start, 
> >+ 	unsigned int num, unsigned int over);
> 
> I think we can simplify this interface:
> 
>    int kevent_commit(int ctl_fd, unsigned int new_tail,
>                      unsigned int over);
> 
> The kernel sets the ring_uidx value to the 'new_tail' value if the tail 
> pointer would be incremented (module wrap around) and is not higher then 
> the current front pointer.  The test will be a bit complicated but not 
> more so than what the current code has to do to check for mistakes.
> 
> This approach has the advantage that the commit calls don't have to be 
> synchronized.  If one thread sets the tail pointer to, say, 10 and 
> another to 12, then it does not matter whether the first thread is 
> delayed.  If it will eventually be executed the result is simply a no-op 
> and since second thread's action supersedes it.
> 
> Maybe the current form is even impossible to use with explicit locking 
> at userlevel.  What if one thread, which is about to call kevent_commit, 
> if indefinitely delayed.  Then this commit request's value is never 
> taken into account and the tail pointer is always short of what it 
> should be.

I like this interface, although current one does not allow special
synchronization in userspace, since it calculates if new commit is in
the area where previous commit was.
Will change for the next release.
 
> There is one more thing to consider.  Oftentimes the commit request will 
> be immediately followed by a kevent_wait call.  It would be good to 
> merge this pair of calls.  The two parameters new_tail and over could 
> also be passed to the kevent_wait call and the commit can happen before 
> the thread looks for new events and eventually goes to sleep.  If this 
> can be implemented then the kevent_commit syscall by itself might not be 
> needed at all.  Instead you'd call kevent_wait() and make the maximum 
> number of events which can be returned zero.

It _IS_ how previous interface worked.

	EXACTLY!

There was one syscall which committed requested number of events and
waited when there are new ready events. The only thing it missed, was
userspace index (it assumed that if userspace waits for something, then
all previous work is done).

Ulrich, I'm not going to think for other people all over the world and
blindly implementing ideas, which in a day or two will be commented as
redundant, since flow of mind has changed, and they had not enough time
to check previous version.

I will wait for some time until you and other people made theirs comments 
on interfaces and release final version in about a week, and now I will
go to hack netchannels.

	NO INTERFACE CHANGES AFTER THAT DAY. 
		COMPLETELY.

So, feel free to think about perfect interface anyone will be happy
with. But please release your thoughts not in form of abstract words,
but more precisely, at least like in this e-mail, so I could understand
what _you_ want from _your_ interface.

> -- 
> â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, 
> CA â

-- 
	Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/