The threads package I wrote (so that this port can be accomplished) is heavily
instrumented. One feature of its instrumentation is that it detects when
threads terminate but still have one or more mutexes locked. Well, that is
exactly what appears to be happening. These threads execute the following
call tree:
rpc_server_listen()
rpc__nlsn_activate_desc()
pthd4_cancel() < DCE compatibility macro
pthread_cancel()
pthread_testcancel()
In the pthread_testcancel() routine, the thread runtime accepts the cancel and
terminates the thread (yes, I've been told that this behavior is acceptable
by POSIX -- Someone correct me if my understanding is incorrect).
Unfortunately, the thread being terminated holds a locked mutex and a message
to this effect gets logged to stdout.
Is this intended behavior?
Second question: From the comments in comnlns.c in the lthread_loop() function
I am assuming that the call to select is assumed to be blocking because the
code sets async cancellability to ON prior to calling select and OFF
immediately
following its return. Is this also intended? In general, what assumptions
does
the DCE RPC library code make vis non-blocking I/O? What are the requirements
it has of the underlying threads facility?
Thanks in advance for any help you may be able to provide. So far, this stuff
is really cool.
/mtp
--
+-----------------------------------------------------------------------+
| Michael T. Peterson | The hell you say. My opinions are my own |
| http://www.aa.net/~mtp/ | and worth every damn cent you paid. |
+-----------------------------------------------------------------------+