From: "Michael Kerrisk" <mtk-manpages@gmx.net>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: rdunlap@xenotime.net, tglx@linutronix.de,
linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
drepper@redhat.com, stable@kernel.org, hch@lst.de,
jengelh@computergmbh.de, corbet@lwn.net,
akpm@linux-foundation.org
Subject: Re: [PATCH] Revised timerfd() interface
Date: Thu, 06 Sep 2007 00:50:33 +0200 [thread overview]
Message-ID: <20070905225033.236700@gmx.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0709051251290.11804@alien.or.mcafeemobile.com>
Hi Davide,
> > > > > > As I think about this more, I see more problems with
> > > > > > your argument. timerfd needs the ability to get and
> > > > > > get-while-setting just as much as the earlier APIs.
> > > > > > Consider a library that creates a timerfd file descriptor that
> > > > > > is handed off to an application: that library may want
> > > > > > to modify the timer settings without having to create a
> > > > > > new file descriptor (the app mey not be able to be told about
> > > > > > the new fd). Your argument just doesn't hold, AFAICS.
> > > > >
> > > > > Such hypotethical library, in case it really wanted to offer such
> > > > > functionality, could simply return an handle instead of the raw
> > > > > fd, and take care of all that stuff in userspace.
> > > >
> > > > Did I miss something? Is it not the case that as soon as the
> > > > library returns a handle, rather than an fd, then the whole
> > > > advantage of timerfd() (being able to select/poll/epoll on
> > > > the timer as well as other fds) is lost?
> > >
> > > Why? The handle would simply be a little struct where the timerfd fd
> > > is
> > > stored, and a XXX_getfd() would return it.
> > > So my point is, I doubt such functionalities are really needed, and I
> > > also argue that the kernel is the best place for such wrapper code
> > > to go.
> >
> > So what happens if one thread (via the library) wants modify
> > a timer's settings at the same timer as another thread is
> > select()ing on it? The first thread can't do this by creating
> > a new timerfd timer, since it wants to affect the select()
> > in the other thread?
>
> It can be done w/out any problems. The select thread will be notified
> whenever the new timer setting expires.
We are going in circles here. I think you are missing my point.
Consider the following
[[
Thread A: calls library function which creates a timerfd file
descriptor.
Thread B: calls select() on the timerfd file descriptor.
Thread A: calls library function which wants to:
a) modify timer settings, and retrieve copy of current timer
settings, and later
b) restore old timer settings.
]]
This seems a quite reasonable use-case to me, and the existing
interface simply can't support it.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages ,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
next prev parent reply other threads:[~2007-09-05 22:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-25 6:41 Michael Kerrisk
2007-08-30 12:01 ` Davide Libenzi
2007-09-04 8:03 ` Michael Kerrisk
2007-09-04 8:18 ` Andrew Morton
2007-09-04 8:24 ` Michael Kerrisk
2007-09-04 15:25 ` Davide Libenzi
2007-09-04 15:39 ` Michael Kerrisk
2007-09-04 22:41 ` Davide Libenzi
2007-09-04 20:49 ` Michael Kerrisk
2007-09-04 22:44 ` Davide Libenzi
2007-09-05 0:08 ` Michael Kerrisk
2007-09-05 12:02 ` Andrew Morton
2007-09-05 16:14 ` Davide Libenzi
2007-09-05 16:23 ` Michael Kerrisk
2007-09-05 19:57 ` Davide Libenzi
2007-09-05 22:50 ` Michael Kerrisk [this message]
2007-09-05 23:45 ` Davide Libenzi
2007-09-06 6:58 ` Michael Kerrisk
2007-09-06 23:37 ` Davide Libenzi
2007-09-10 3:15 ` Michael Kerrisk
2007-09-05 12:12 ` Denys Vlasenko
2007-09-05 15:32 ` timerfd redux Michael Kerrisk
2007-09-13 2:39 ` Andrew Morton
2007-09-13 6:14 ` Michael Kerrisk
2007-09-13 8:13 ` Michael Kerrisk
2007-09-13 8:20 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2007-07-23 6:32 Problems with timerfd() Michael Kerrisk
2007-07-23 6:38 ` Andrew Morton
2007-07-25 18:18 ` Michael Kerrisk
2007-07-25 22:12 ` Andrew Morton
2007-08-07 6:55 ` Michael Kerrisk
2007-08-09 21:11 ` [PATCH] Revised timerfd() interface Michael Kerrisk
2007-08-13 23:34 ` Randy Dunlap
2007-08-15 14:40 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070905225033.236700@gmx.net \
--to=mtk-manpages@gmx.net \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=davidel@xmailserver.org \
--cc=drepper@redhat.com \
--cc=hch@lst.de \
--cc=jengelh@computergmbh.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
--cc=stable@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome