On 2/2/2017 1:25 PM, Branko Čibej wrote:
On 02.02.2017 13:14, Stefan Hett wrote:
On 2/2/2017 12:52 PM, Branko Čibej wrote:
On 01.02.2017 00:23, Stefan wrote:
Hi,
the issue was discovered as part of tracing down a deadlock
condition in
an SVN test [1].
[...]
In this particular case we create a couple of threads and before the
threads terminate the calling process terminates. At this point
apr_terminate() is called which got registered via the atexit()-call
(as
suggested in the apr_terminate-documentation).
This is incorrect. apr_terminate() is not called after the calling
process terminates; that would make no sense at all: if there's no
process, it cannot execute any code.
Handlers registered with atexit() are called "when the program
terminates normally": either when exit() is called, or when main()
returns, and certainly _before_ the process terminates.
[...]
Another example of my bad expression and usage of incorrect
terminology. Sorry for that.
In this particular case we create a couple of threads and before the
threads terminate the calling process terminates.
This should actually read:
In this particular case we create a couple of threads and before these
threads finish (i.e. before the threads get to return from their
thread_pool_func() function) the process' main function returns.
Hope this makes a bit more sense now. :-)
It does and there's nothing wrong with that, that's perfectly normal and
expected.
Right, but what's not expected is that the threads terminated without
actually getting to the return statements in thread_pool_func() and
hence did not decrease the thd_cnt-variable, or is it? In that case I'm
really missing something.
--
Regards,
Stefan Hett