Mail Archives: djgpp-workers/2001/01/07/15:32:59
Bonjour
>
> On Sun, 7 Jan 2001, Alain Magloire wrote:
>
> > 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.
> 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.
> 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. But
we are talking about "async-signal safe", POSIX defines a number that
are require to be "async-signal safe". Some are not and from the one
that are not malloc() and friends spring to mind. Using malloc() etc ..
in a signal handler is totally unportable. Those functions usually
use static data structures or use global data structures that makes
them nonreentrant. i.e. If you call malloc() and get interrupted
by a signal inside the malloc() call and in the sig handler you recall
malloc()/realloc()/memaling() again there is chance that the internal
structures(chain, freelist, link list, etc ...) were in unstable state.
If in DJGPP, you guys found a way, to make it possible for malloc()
calls to be reentrant .... great.
--
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!
- Raw text -