LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Ulrich Drepper <drepper@redhat.com> To: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Cc: Ulrich Drepper <drepper@gmail.com>, lkml <linux-kernel@vger.kernel.org>, David Miller <davem@davemloft.net>, Andrew Morton <akpm@osdl.org>, netdev <netdev@vger.kernel.org>, Zach Brown <zach.brown@oracle.com>, Christoph Hellwig <hch@infradead.org>, Chase Venters <chase.venters@clientec.com> Subject: Re: [take19 0/4] kevent: Generic event handling mechanism. Date: Sun, 15 Oct 2006 15:43:39 -0700 [thread overview] Message-ID: <4532B99B.9030403@redhat.com> (raw) In-Reply-To: <20061006083620.GA28009@2ka.mipt.ru> Evgeniy Polyakov wrote: > In context you have cut, one updated signal mask between calls to event > delivery mechanism (using for example signal()), so it has exactly the > same price. No, it does not. If the signal mask is recomputed by the program for each new wait call then you have a lot more work to do when the signal mask is implicitly specified. > I created it just because I think that POSIX workaround to add signals > into the syscall parameters is not good enough. Not good enough? It does exactly what it is supposed to do. What can there be "not good enough"? > You again cut my explanation on why just pure timeout is used. > We start a syscall, which can block forever, so we want to limit it's > time, and we add special parameter to show how long this syscall should > run. Timeout is not about how long we should sleep (which indeed can be > absolute), but how long syscall should run - which is related to the > time syscall started. I know very well what a timeout is. But the way the timeout can be specified can vary. It is often useful (as for select, poll) to specify relative timeouts. But there are equally useful uses where the timeout is needed at a specific point in time. Without a syscall interface which can have a absolute timeout parameter we'd have to write as a poor approximation at userlever clock_gettime (CLOCK_REALTIME, &ts); struct timespec rel; rel.tv_sec = abstmo.tv_sec - ts.tv_sec; rel.tv_nsec = abstmo.tv_sec - ts.tv_nsec; if (rel.tv_nsec < 0) { rel.tv_nsec += 1000000000; --rel.tv_sec; } if (rel.tv_sec < 0) inttmo = -1; // or whatever is used for return immediately else inttmo = rel.tv_sec * UINT64_C(1000000000) + rel.tv_nsec; wait(..., inttmo, ...) Not only is this much more expensive to do at userlevel, it is also inadequate because calls to settimeofday() do not cause a recomputation of the timeout. See Ingo's RT futex stuff as an example for a kernel interface which does it right. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
next prev parent reply other threads:[~2006-10-15 22:45 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <115a6230591036@2ka.mipt.ru> 2006-09-12 8:41 ` [take18 0/4] kevent: Generic event handling mechanism Evgeniy Polyakov 2006-09-12 8:41 ` [take18 1/4] kevent: Core files Evgeniy Polyakov 2006-09-12 8:41 ` [take18 2/4] kevent: poll/select() notifications Evgeniy Polyakov 2006-09-12 8:41 ` [take18 3/4] kevent: Socket notifications Evgeniy Polyakov 2006-09-12 8:41 ` [take18 4/4] kevent: Timer notifications Evgeniy Polyakov 2006-09-20 9:35 ` [take19 0/4] kevent: Generic event handling mechanism Evgeniy Polyakov 2006-09-20 9:35 ` [take19 1/4] kevent: Core files Evgeniy Polyakov 2006-09-20 9:35 ` [take19 2/4] kevent: poll/select() notifications Evgeniy Polyakov 2006-09-20 9:35 ` [take19 3/4] kevent: Socket notifications Evgeniy Polyakov 2006-09-20 9:35 ` [take19 4/4] kevent: Timer notifications Evgeniy Polyakov 2006-10-04 6:34 ` [take19 1/4] kevent: Core files Ulrich Drepper 2006-10-04 6:48 ` Evgeniy Polyakov 2006-10-04 17:57 ` Ulrich Drepper 2006-10-05 8:57 ` Evgeniy Polyakov 2006-10-05 9:56 ` Eric Dumazet 2006-10-05 10:21 ` Evgeniy Polyakov 2006-10-05 10:45 ` Eric Dumazet 2006-10-05 10:55 ` Evgeniy Polyakov 2006-10-05 12:09 ` Eric Dumazet 2006-10-05 12:37 ` Evgeniy Polyakov 2006-10-15 23:22 ` Ulrich Drepper 2006-10-16 7:33 ` Evgeniy Polyakov 2006-10-16 10:16 ` Ulrich Drepper 2006-10-16 11:23 ` Evgeniy Polyakov 2006-10-17 5:10 ` Johann Borck 2006-10-17 5:59 ` Chase Venters 2006-10-17 10:42 ` Evgeniy Polyakov 2006-10-17 13:12 ` Chase Venters 2006-10-17 13:35 ` Evgeniy Polyakov 2006-10-17 10:39 ` Evgeniy Polyakov 2006-10-17 13:19 ` Eric Dumazet 2006-10-17 13:42 ` Evgeniy Polyakov 2006-10-17 13:52 ` Eric Dumazet 2006-10-17 14:07 ` Evgeniy Polyakov 2006-10-17 14:25 ` Eric Dumazet 2006-10-17 15:09 ` Evgeniy Polyakov 2006-10-17 15:32 ` Eric Dumazet 2006-10-17 16:01 ` Evgeniy Polyakov 2006-10-17 16:26 ` Eric Dumazet 2006-10-17 16:35 ` Evgeniy Polyakov 2006-10-17 16:45 ` Eric Dumazet 2006-10-18 4:10 ` Evgeniy Polyakov 2006-10-18 4:45 ` Eric Dumazet 2006-10-17 15:33 ` Hans Henrik Happe 2006-10-05 14:01 ` Hans Henrik Happe 2006-10-05 14:15 ` Evgeniy Polyakov 2006-10-05 15:07 ` Hans Henrik Happe 2006-09-22 19:22 ` [take19 0/4] kevent: Generic event handling mechanism Andrew Morton 2006-09-23 4:23 ` Evgeniy Polyakov 2006-10-04 6:09 ` Ulrich Drepper 2006-10-04 6:10 ` Ulrich Drepper 2006-10-04 6:27 ` Evgeniy Polyakov 2006-10-04 6:24 ` Evgeniy Polyakov 2006-09-26 15:54 ` Christoph Hellwig 2006-09-27 4:46 ` Evgeniy Polyakov 2006-09-27 15:09 ` Evgeniy Polyakov 2006-10-04 4:50 ` Ulrich Drepper 2006-10-04 4:55 ` Evgeniy Polyakov 2006-10-04 7:33 ` Ulrich Drepper 2006-10-04 7:48 ` Evgeniy Polyakov 2006-10-04 17:20 ` Ulrich Drepper 2006-10-05 9:02 ` Evgeniy Polyakov 2006-10-05 14:45 ` Ulrich Drepper 2006-10-06 8:36 ` Evgeniy Polyakov 2006-10-15 22:43 ` Ulrich Drepper [this message] 2006-10-16 7:23 ` Evgeniy Polyakov 2006-10-16 9:59 ` Ulrich Drepper 2006-10-16 10:38 ` Evgeniy Polyakov
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=4532B99B.9030403@redhat.com \ --to=drepper@redhat.com \ --cc=akpm@osdl.org \ --cc=chase.venters@clientec.com \ --cc=davem@davemloft.net \ --cc=drepper@gmail.com \ --cc=hch@infradead.org \ --cc=johnpol@2ka.mipt.ru \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=zach.brown@oracle.com \ /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: linkBe 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; as well as URLs for NNTP newsgroup(s).