Dan Lukes wrote:
On Mon, 6 Apr 2009, David Houlder wrote:
I don't think longjmp() is async signal safe.
You need to specify environment we are talking about. IEEE Std 1003.1
declare:
----------------
As it bypasses the usual function call and return mechanisms,
longjmp() shall execute correctly in contexts of interrupts, signals,
and any of their associated functions.
...
----------------
This is extension against ISO C which lack such declaration. It mean
the ISO C longjmp may or may not work here.
So POSIX longjmp is signal safe, ISO C longjmp is not safe unless a
specific implementation declare similar extension against ISO C.
----------------
So linux and the open src community are moving away from some previously
met POSIX standards? Sounds like the wrong direction. Is it that glibc
is less POSIX compatible than what it replaced, i.e. 'libc'? (was libc
gnu? I'm guessing glibc is and
was designed as some top-level redesign?) It would be a shame to move
away from
previous unix compatibility (as many or most tried to be POSIX
compliant). It was
one of the few standards everyone could point to and agree on.
Maybe the people switching the libraries in and out aren't aware of what
they are
trading away, or the new library sources aren't aware that the old libc
used to be
POSIX compatible in this regard? It's really one of those issues that
could easily fall into a crack without an overall development plan or
project coordinator to make sure new software maintains the POSIX
compatibility of the old libc. I know in the open source world there
usually aren't such such "meta-people".
Similarly, it's unknown what the previous libc compatibility was. If
one of you
knows the developer working on 'glibc', maybe nudging them with prior
version
compatibility might have them make it 'safe' again. Certainly, these
problems
of global aborts in 'threads' aren't going to get "less prevalent" as we
move
to more cores. If there's a well defined standard as in POSIX, for how
things
should behave in such circumstances, it should be supported.
Multi-threaded and/or multi-processor programming is hard enough without
dropping out functions that previously worked in a such an environment.
I'd say it's positively discouraging (if not the death knell for open
source
software). If core libraries are not maintaining backward
multi-threaded/process synchronization and not moving toward better
synchronization paradigms, Open
Source will fall by the way-side as processors are build with more cores.
It appears that a previously thread-safe call in the most prevalently used
C-library has become 'unsafe' through neglect or by design I'd bet it
was by 'neglect' and can't see why they wouldn't want to support
deterministic behavior, but hey, maybe random behavior of error handlers
is designed to evoke
a random behavior {halt&catch fire, electrify keyboard; display
something like
"ABEND 2816" or "A required system function is not found, this program
cannot
continue execution(5024)". (sigh)
Linda
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
