The easiest way to think about it is to consider function foo that uses a global variable (bar) to store some data. Now if foo is being called and has modified bar, and foo is called again (by the same process) before its first invocation is done bar may not be set properly and could cause foo to behave abnormally (the "totally confused and crashing" effect mentioned in "Advanced Perl Programming"). In most cases it will just cause a program error, but malloc is such so intimate w/ the system that a problem there could lead to overlapping blocks of allocated memory w/ another process, etc...
Consider this (really bogus, but demonstrates the point) example:
(for this example, pretend that signals don't mess up sleep calls, even though they do) Now when foo is called it will sleep for 5 seconds and return a time 20 seconds after it was called.. However, if foo were called, and during the sleep a signal caused foo to be called again the program wouldn't crash, but the first foo would return a wrong value (a value different from what it would have returned it it had not been interrupted).my $bar; sub foo{ $bar=time(); sleep 5; return $bar+20; }
In non-threaded programming this problem is pretty-much limited to signal and exception handlers. However when you're dealing w/ a threaded application you need to be very careful about possible code reentrance.
In general in signal handlers you should not be doing much work.
Les Howard
www.lesandchris.com
Author of Net::Syslog and Number::Spell
In reply to Re: Malloc is not reentrant?
by lhoward
in thread Malloc is not reentrant?
by floopy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |