Message135083
> 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). |
|
Date |
User |
Action |
Args |
2011-05-03 22:05:37 | pitrou | set | recipients:
+ pitrou, gregory.p.smith, bobbyi, neologix |
2011-05-03 22:05:36 | pitrou | link | issue6721 messages |
2011-05-03 22:05:36 | pitrou | create | |
|