Messages in this thread | | | Subject | Re: light weight user level semaphores | Date | Fri, 20 Apr 2001 00:35:57 +0200 (MEST) | From | (Rogier Wolff) |
| |
Alan Cox 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. > > > > You want to take the bet? > > Its not normally a good idea to take a Linus bet, but this time Im obviously > missing something. fd0-2 will be passed in (and if not then shit already > happens - see old bugtraq on the matter for setuid apps, glibc bugs) > > So the C library gets fd 3 > My first fopen gets fd 4.
Code may close (0); close (1); close (2); ... malloc ();
/* Now open our controlling TTY/ stdin .. */ fd = open (... ) ;
After taking care of this (*), problem I find the fd trick WAY more appealing than Linus' magic numbers. With file descriptors we have a "small integer which can be validated quickly". We also have storage for a private pointer somewhere in the fd structure.
If people are TOO afraid of breaking something, creating a new set of small integers handled similarly as "fds" would do fine. (Maybe here we'd allocate just a few, and reallocate when neccesary).
Roger.
(*) I bet that get_sem_fd () { int rv; int fd; fd = get_fd (); if (fd < 5) { rv = get_sem_fd (); close(fd); fd = rv; } return fd; }
will not break much. (UGLY coding. Don't tell me.)
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - 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/
| |