homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients bobbyi, gregory.p.smith, neologix, pitrou
Date 2011年05月03日.22:05:36
SpamBayes Score 5.355187e-05
Marked as misclassified No
Message-id <1304460331.3567.18.camel@localhost.localdomain>
In-reply-to <1304458797.39.0.439682215209.issue6721@psf.upfronthosting.co.za>
Content
> Also, this would imply keeping track of the thread currently owning
> the lock,
Yes, we would need to keep track of the thread id and process id inside
the lock. We also need a global variable of the main thread id after
fork, and a per-lock "taken" flag.
Synopsis:
 def _reinit_if_needed(self):
 # Call this before each acquire() or release()
 if self.pid != getpid():
 sem_init(self.sem, 0, 1)
 if self.taken:
 if self.tid == main_thread_id_after_fork:
 # Lock was taken in forked thread, re-take it
 sem_wait(self.sem)
 else:
 # It's now released
 self.taken = False
 self.pid = getpid()
 self.tid = current_thread_id()
> and doesn't match the typical pthread_atfork idiom (acquire locks just
> before fork, release just after in parent and child, or just reinit
> them in the child process)
Well, I fail to understand how that idiom can help us. We're not a
self-contained application, we're a whole programming language.
Calling fork() only when no lock is held is unworkable (for example, we
use locks around buffered I/O objects).
History
Date User Action Args
2011年05月03日 22:05:37pitrousetrecipients: + pitrou, gregory.p.smith, bobbyi, neologix
2011年05月03日 22:05:36pitroulinkissue6721 messages
2011年05月03日 22:05:36pitroucreate

AltStyle によって変換されたページ (->オリジナル) /