Hi Linda -
I wish that I knew the answers to your questions. It does seem to me that
the developers of recent versions of C library are more concerned with
multi-threaded applications that traditional single-threaded applications
that take signals.
Case in point. Traditionally, putc() and putchar() were macros whose
intent was to be fast. Since stdio buffers, this meant that a programmer
could reasonably call putc() in a tight loop, e.g.,
while (c = *s++) putchar (c ^ 0xff);
instead of something like:
t = buf;
while (c = *s++) *t++ = c ^ 0xff;
fwrite (buf,1,t-buf,stdout);
This is no longer the case. In order to make putc()/putchar() be
thread-safe, there is now a mutex in these operations which slow them down
immensely (a colleague of mine was claiming 3 orders of magnitude). If
you want the good old functions, you now must use putc_unlocked() and
putchar_unlocked(). This is actually part of POSIX.1-2001, and you get
this by default!
Lots and lots of old programs took a big performance hit because of this,
but most people didn't notice since few programs did enough consecutive
putchar()s to notice. My colleague noticed when he upgraded his machine
and noticed that a data conversion app was much slower on the newer,
faster machine...
It should be possible for a program to take a signal, decide NOT to resume
whatever it was doing, and instead issue a syslog message and exit. But,
in the new wonderful (sarcasm intended) world, this can't be done any
more.
I was told in no uncertain terms that, becaused of the mutexes, you can
NOT do a syslog() in a signal handler, not even if you have no intent of
ever returning from the signal handler.
The other argument is "what if the code was in the middle of doing
something to the heap at the time". Well, back in the old days, code that
did critical stuff like that would defer signals so you couldn't ever get
a signal in the middle of critical stuff. That's why signal deferrals
exist. But, in the new wonderful (sarcasm again) world, this
"inefficiency" has been "fixed".
Anyway, I have someone testing a theory of the cause of the corruptions;
and if that theory is correct, I'll have a new signal handling algorithm
in Panda IMAP that avoids the problem.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
