Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.sysv386
Subject: Re: malloc() problem solved(?)
Message-ID: <1991Apr10.144136.13350@virtech.uucp>
Date: 10 Apr 91 14:41:36 GMT
References: <1991Apr09.215120.1734@dialogic.com>
Organization: Virtual Technologies Inc.
Lines: 27

drich@dialogic.com (Dan Rich) writes:
>So, it looks like the solution to this problem is to not put mallocs
>in your signal handlers.  :-(

Signal handlers, like the low level kernel stuff, must ensure that 
they don't do something that will effect the outside world without
ensuring that they cannot be interrupted.  This includes mallocs, 
changes to global data (especially pointers), etc.

The kernel's solution is to lock out interrupts that may collide.  C
programs can do the same with signals (put the problem signals in
a hold status - see sigset()).  However, you still end up with the 
limitation that must be very carefull about modifying global
pointers.

The complete answer to the malloc problem would include changes to 
malloc that locked out problem signals while the malloc was being 
performed.

Remember, signal handlers can be called when you code is at 
any location (although because of the way the kernel implements them
they will usually be called near a system call).

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170