Mail Archives: djgpp-workers/2001/01/07/19:44:03
Bonjour
> > Date: Sun, 7 Jan 2001 15:31:46 -0500 (EST)
> > From: "Alain Magloire" <alain AT qnx DOT com>
> > >
> > > > 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 !!!
- Raw text -