Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!ub!acsu.buffalo.edu
From: jones@acsu.buffalo.edu (terry a jones)
Newsgroups: comp.unix.sysv386
Subject: Re: malloc() problem solved(?)
Message-ID: <70183@eerie.acsu.Buffalo.EDU>
Date: 10 Apr 91 18:18:29 GMT
References: <1991Apr09.215120.1734@dialogic.com> <1991Apr10.144136.13350@virtech.uucp>
Sender: news@acsu.Buffalo.EDU
Organization: SUNY Buffalo
Lines: 24
Nntp-Posting-Host: beatrix.eng.buffalo.edu

In article <1991Apr10.144136.13350@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
>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.
>


	Or put another way, make sure that your interrupt level code never
calls routines that are not re-entrant, period.  You may get away with it
99.99% of the time, but calling a non re-entrant version of malloc() in an
interrupt thread that has interrupted another thread that was itself 
executing malloc() can give you big trouble.


	Terry


Terry Jones   				{rutgers,uunet}!acsu.buffalo.edu!jones
SUNY at Buffalo ECE Dept.	  or: rutgers!ub!jones, jones@acsu.buffalo.edu