Message-Id: <200101080042.TAA17315@qnx.com> Subject: Re: valloc and memalign draftu To: djgpp-workers AT delorie DOT com Date: Sun, 7 Jan 2001 19:42:31 -0500 (EST) From: "Alain Magloire" In-Reply-To: <5567-Mon08Jan2001005421+0200-eliz@is.elta.co.il> from "Eli Zaretskii" at Jan 08, 2001 12:54:22 AM X-Mailer: ELM [version 2.5 PL0b1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Bonjour > > Date: Sun, 7 Jan 2001 15:31:46 -0500 (EST) > > From: "Alain Magloire" > > > > > > > I did not follow the thread but malloc and friends cannot be made > > > > async-safe. What you're describing is undefined behaviour or a programming > > > > error i.e. calling a none async-safe routine in a signal handler. > > > > > > malloc isn't documented in DJGPP as non-safe in this context. In DJGPP, > > > > ?? > > Then out of curiosity what context are you refering too. > > I was referring to the context of a signal handler. We don't say in > the library docs that a signal handler cannot call malloc. By default functions are assumed to not be async-signal safe save unless specify otherwise. > > > signal handlers are called in the normal user context (unlike on Unix), > > > > By this do you mean, on many other OS implementations, the signal handler > > is run on a separate stack. There are good reasons for doing it this way. > > Of course, there are good reasons to do that. Except that in DJGPP, > these reasons don't exist. Well one of the obvious reason, is if you reach your stack limit and been hit by a SIGVEC or something, running the handler on an alternate stack will allow you to recuperate. > > > so the handler and the code it runs is generally allowed to do anything > > > that normal C code is allowed to do. > > > > I'm not sure I follow or understand what make DJGPP so particular. > > What makes DJGPP special is the way signal-handling machinery is > implemented. > [... explanation deleted for brievity] Thanks !! For the explanation, I was always curious about that, appreciated. > So, by the time the user-defined signal handler's code runs, the > program is in a safe state, with all the segment registers set up as > they are for normal vanilla C code. It therefore can in principle do > anything a vanilla C code can. Yes you are in a state, but not necessarly in a "safe" state. Suppose the malloc implementation is done with a double link list. The first time you call malloc(), the code is in that list rearranging the next/previous pointers. You get hit by a signal, note the dlist has dangling pointers since it did not finish its job. The sighangler is run and call malloc() again but the dlist is in a bad state, .. undefined behaviour. Not all functions can be call in a signal handler(stdio, malloc(), .. etc are the ones that comes to mind). POSIX.1 specify a list of functions that should be async-signal safe. > > If in DJGPP, you guys found a way, to make it possible for malloc() > > calls to be reentrant .... great. > > I don't know if malloc is reentrant. But if it isn't, that should be > documented, since I don't think the users should guess. The term "reentrant" can be confusing, malloc() or strtok() can be made "reentrant" i.e. thread-safe. Multiple threads can call the code, the thread-safeness is provided by locking a mutex, changing the API i.e. strtok_r() or saving the information in a thread-local storage. But they are not necessarly "reentrant" in term of async-safe. This was off-topic, but reentrant is sometimes use when people mean thread-safe. A function in a library, should be consider not async-signal safe unless specify otherwise. By the way this does not mean that you can not use say malloc in a signal handler, it is for the programmer to evaluate and take the necessary protections, meaning that yes, the programmer can certainly call malloc/memalign etc ... in his/her applications. The C-library just say, that there is a list of functions that are known to be safe in sig handlers but if you want to use the others ... ok but be carefull you may get in to troube(undefine behaviour) > One thing to keep in mind is that signals are sometimes used to > implement sophisticated features, such as threading (there are a > couple of such packages which work with DJGPP), where threads are run > from within a SIGALRM handler. And threads can call malloc. A good thread library will take the necessary protection. For example a cooperative threading or non-preemptive threading does not need special protection, since the context switches are done on "secure" points for example on blocking functions like read()/connect(), etc .. Preemptive libraries, example the FSU pthreads, provide wrappers, they will wrap a certain number of calls, for example malloc/realloc etc .. will be wrap, when they are call context switching will be disable. For the other libs that do not provide provisions for this, one should call sigblock() or something to disable context switch before calling those functions. -- au revoir, alain ---- Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!