From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, Alon Ziv <alonz@nolaviz.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mike Kravetz <mkravetz@sequent.com>,
Ulrich Drepper <drepper@cygnus.com>
Subject: Re: light weight user level semaphores
Date: Mon, 23 Apr 2001 21:18:01 +0200 [thread overview]
Message-ID: <20010423211801.U682@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <E14qHRp-0007Yc-00@the-village.bc.nu> <Pine.LNX.4.31.0104190944090.4074-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.31.0104190944090.4074-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Thu, Apr 19, 2001 at 09:46:17AM -0700
On Thu, Apr 19, 2001 at 09:46:17AM -0700, Linus Torvalds wrote:
> > libc is entitled to, and most definitely does exactly that. Take a look at
> > things like gethostent, getpwent etc etc.
>
> Ehh.. I will bet you $10 USD that if libc allocates the next file
> descriptor on the first "malloc()" in user space (in order to use the
> semaphores for mm protection), programs _will_ break.
But we would not open the semaphore on malloc() but instead in
the init functions of the libc. So the semaphore will be already
allocated. May be dup2()ed to some very high range
(INT_MAX-__GLIBC_MALLOC_SEM_FD) and the original fd closed.
So this will be no real problem. That's why I don't like lazy
init: May be you cannot init anymore, if you come to and
condition, where you would need it.
Also init/fini are usally very slow operations and as many things
as possible are burdend onto their shoulders.
Semaphores tend to be structures living very long (at least in
all code I've written and seen so far) so I see no point in
defering their initialization.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< been there and had much fun >>>>>>>>>>>>
next prev parent reply other threads:[~2001-04-23 19:18 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010417114433.D1108@w-mikek2.sequent.com>
2001-04-17 19:48 ` Linus Torvalds
2001-04-18 18:13 ` Bernd Eckenfels
2001-04-18 19:35 ` Ulrich Drepper
2001-04-19 8:20 ` Alon Ziv
2001-04-19 8:52 ` Abramo Bagnara
2001-04-19 9:08 ` Alexander Viro
2001-04-19 10:44 ` Abramo Bagnara
2001-04-19 16:11 ` Linus Torvalds
2001-04-19 16:33 ` Alexander Viro
2001-04-19 16:43 ` Linus Torvalds
2001-04-19 17:33 ` Alexander Viro
2001-04-19 17:38 ` Linus Torvalds
2001-04-19 18:24 ` Alexander Viro
2001-04-19 19:26 ` Ulrich Drepper
2001-04-19 19:35 ` Alan Cox
2001-04-19 20:06 ` Ulrich Drepper
2001-04-19 20:11 ` Alan Cox
2001-04-19 20:26 ` Ulrich Drepper
2001-04-19 20:22 ` Ingo Oeser
2001-04-19 20:40 ` Ulrich Drepper
2001-04-19 20:51 ` Linus Torvalds
2001-04-19 21:38 ` Alan Cox
2001-04-19 20:49 ` Linus Torvalds
2001-04-19 21:18 ` Ulrich Drepper
2001-04-19 21:41 ` Linus Torvalds
2001-04-19 22:46 ` Ulrich Drepper
2001-04-20 1:35 ` Alexander Viro
2001-04-20 2:45 ` Ulrich Drepper
2001-04-19 16:43 ` Abramo Bagnara
2001-04-19 20:47 ` Ingo Oeser
2001-04-19 20:54 ` Linus Torvalds
2001-04-19 9:08 ` Ingo Oeser
2001-04-19 11:51 ` Alan Cox
2001-04-19 16:03 ` Linus Torvalds
2001-04-19 16:38 ` Alan Cox
2001-04-19 16:46 ` Linus Torvalds
2001-04-19 17:12 ` Alan Cox
2001-04-19 22:35 ` Rogier Wolff
2001-04-20 9:29 ` Olaf Titz
2001-04-20 14:19 ` Jesse Pollard
2001-04-20 18:36 ` Olaf Titz
2001-04-20 23:33 ` Linus Torvalds
2001-04-21 4:06 ` fd allocation [was: light weight user level semaphores] Edgar Toernig
2001-04-22 9:48 ` Olaf Titz
2001-04-22 11:41 ` light weight user level semaphores Alon Ziv
2001-04-22 12:44 ` Alan Cox
2001-04-22 15:19 ` Alon Ziv
2001-04-22 14:31 ` Alexander Viro
2001-04-22 16:08 ` Alon Ziv
2001-04-22 11:41 ` Alon Ziv
2001-04-22 14:18 ` David Woodhouse
2001-04-23 13:19 ` David Howells
2001-04-23 14:48 ` Alon Ziv
2001-04-23 15:40 ` David Howells
2001-04-21 10:13 ` Olaf Titz
2001-04-23 15:34 ` Jeff Garzik
2001-04-23 19:18 ` Ingo Oeser [this message]
2001-04-24 0:19 ` David Wagner
2001-04-24 0:41 ` Alexander Viro
2001-04-19 19:47 ` Ulrich Drepper
2001-04-19 18:48 ` Olaf Titz
2001-04-19 13:59 George Talbot
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=20010423211801.U682@nightmaster.csn.tu-chemnitz.de \
--to=ingo.oeser@informatik.tu-chemnitz.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=alonz@nolaviz.org \
--cc=drepper@cygnus.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mkravetz@sequent.com \
--cc=torvalds@transmeta.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: 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
all inboxes | Powered by JetHome®