Yes, you are right, it's my mistake:) the pthread_atfork only register some<br>clean handler.<br><br><div><span class="gmail_quote">On 4/6/07, <b class="gmail_sendername">Kevin P. Fleming</b> <<a href="mailto:kpfleming@digium.com">
kpfleming@digium.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Yuan Qin wrote:<br><br>> The ast_log() will lock a mutex if appropriate, but the mutex may be in
<br>> locked state already.<br>> Maybe we should use pthread_atfork() instead of fork() or never call<br>> some functions that hold mutex<br>> before execv() in child process.<br><br>pthread_atfork() does not fork, it does something entirely different.
<br>Read the man page before suggesting we use it :-)<br><br>However, you have raised a very valid point... we cannot use<br>pthread-related functions for synchronization after forking, because we<br>are not running in the same process any longer. I will have someone look
<br>into this, thanks for raising the issue!<br>_______________________________________________<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a> --<br><br>asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br>
Regards