lesha <pybug.20.le...@xoxy.net> added the comment:

This is a reply to: http://bugs.python.org/issue6721#msg151266

Charles-François raises two problems:

1) LinuxThreads have different PIDs per thread. He then points out that 
LinuxThreads have long been deprecated.

2) you cannot release locks on fork() because that might let the forked process 
access protected resources.

My replies:

(1) Good catch. I suspect that this could be mitigated even if we cared about 
LinuxThreads. I haven't looked, but there's got to be a way to determine if we 
are a thread or a fork child.

(2) I think I didn't explain my idea very well. I don't mean that we should 
release *all* locks on fork. That will end in disaster, as Charles-François 
amply explained.

All I meant is that we could introduce a special lock class "ForkClearedRLock" 
that self-releases on fork(). We could even use Charles-François's reinit magic 
for this.

Using ForkClearedRLock in "logging" would prevent deadlocks. The only potential 
harm that would come from this is that your logfile might get pretty ugly, i.e. 
the fork parent and child might be printing simultaneously, resulting in logs 
like:

Error: parentparentparError: childchildchildchildchild
entparentparent

It's not great, but it's definitely better than deadlocking.

I don't think logging can do anything more sensible across fork() anyway.

Did this explanation make more sense?

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to