cechew@moncsbruce.oz (Earl Chew) (05/02/88)
Has anyone addressed the problem of reentrancy in the Minix library? I came across a problem the other day, which I think is due to the Minix library NOT being reentrant (or perhaps just most of it not being reentrant). I had a process which called signal(SIGALRM, do_alarm) and then called alarm(1). Within do_alarm() there is a subsequent call to signal() to reset the signal handler and a call alarm(1). The main body of the process goes about and does read(). STRANGE things happen. I think that the cause of this is that the library sends messages to Minix using a message structure M which is GLOBAL. read() and friends use this to summon Minix. So does signal() and alarm().... Comments? I've also noticed that atoi() (and a few others, but this one in particular) uses a static. Why, when automatics would suffice? Earl Chew
brucee@runx.ips.oz (Bruce Evans) (05/22/88)
The author of the original article informed me about the following fundamental problem: It is impossible to pass messages on the stack to the kernel, since the kernel explicitly checks (in proc.c/mini_send()) that all user messages are in the DATA segment (as opposed to the STACK segment). This seems like an oversight, since stack and data are much the same in C. Of course, an extra check to allow the stack segment will mainly slow down the kernel. Is there anything more to it than this? Bruce Evans Internet: brucee@runx.ips.oz.au UUCP: uunet!runx.ips.oz.au!brucee
ast@cs.vu.nl (Andy Tanenbaum) (05/25/88)
In article <1532@runx.ips.oz> brucee@runx.ips.oz (Bruce Evans) writes: > >It is impossible to pass messages on the stack to the kernel, since the >kernel explicitly checks (in proc.c/mini_send()) that all user messages >are in the DATA segment (as opposed to the STACK segment). > >This seems like an oversight, since stack and data are much the same in C. >Of course, an extra check to allow the stack segment will mainly slow >down the kernel. Is there anything more to it than this? In an early version of MINIX, around V1.-15 or so, you could have messages in either stack or data space. This version also swapped, had shared text, sticky bits, and proper message queues instead of Ada-rendezvous like message passing as is currently there. Unfortunately, this version was not real speedy, so a few features got lopped off, including messages in stack space. This feature is rarely needed, and does have a substantial performance penalty, as the kernel must check which segment the message is in, and if the entire message is within the segment, etc. Andy Tanenbaum (ast@cs.vu.nl)