[omniORB] giopServer::deactivate hangs
baileyk at schneider.com
baileyk at schneider.com
Thu Jun 26 11:21:34 BST 2003
duncan at grisby.org wrote:
> Forking from multi-threaded programs often causes odd things to
> happen. It's safer to Pre-fork before B becomes multi-threaded, then
> have a single threaded forker, F, which talks to B through pipes. That
> way, C would be a child of F, rather than directly of B.
The only thing I do between fork and exec is dup2() and close() calls.
Hopefully I'm OK. My Solaris app is using libpthread, so fork() is acting
like the Solaris fork1().
> It's not guaranteed to be safe to signal a condition variable from
> inside a signal handler. The only threading primitive which is
> guaranteed safe is the System V semaphore.
That makes sense. You specifically say "System V semaphore", but I've done
some reading and it appears the POSIX sem_post is async-signal safe. The
Linux sem_post man page says
DESCRIPTION
This manual page documents POSIX 1003.1b semaphores, not
to be confused with SystemV semaphores as described in
ipc(5), semctl(2) and semop(2).
and later
ASYNC-SIGNAL SAFETY
On processors supporting atomic compare-and-swap (Intel
486, Pentium and later, Alpha, PowerPC, MIPS II, Motorola
68k), the sem_post function is async-signal safe and can
therefore be called from signal handlers. This is the only
thread synchronization function provided by POSIX threads
that is async-signal safe.
On the Intel 386 and the Sparc, the current LinuxThreads
implementation of sem_post is not async-signal safe by
lack of the required atomic operations.
The Solaris sem_post man page claims async-signal safety though. So I can
use sem_post on Solaris/Sparc or Linux/Intel, but not Linux/Sparc? I'm OK
with that. I'll use a POSIX semaphore to wake the thread that calls
ORB::shutdown(), or maybe just use sigwait(). It would be nice if omniORB
provided an API for "shutdown by signal" even though there's no OMG
standard for one. I'd prefer not to use a CORBA invocation to trigger
shutdown.
The hanging threads weren't related to the condition variable though. I'll
try a CVS omniORB snapshot sometime. Right now I can get by without this
stuff working perfectly. I'll post results if I get around to rebuilding a
omniORB.
Thanks,
Kendall
More information about the omniORB-list
mailing list