Kevin Ryde <[EMAIL PROTECTED]> writes: > Sound bizarre. Maybe hacking scm_i_pthread_mutex_init to force the > use of the "error checking" mutex attribute and then hacking > scm_i_pthread_mutex_lock and scm_i_pthread_mutex_unlock to check the > return and errno would show something. Dunno what though.
See pthread_atfork(3): To understand the purpose of !pthread_atfork!, recall that !fork!(2) duplicates the whole memory space, including mutexes in their current locking state, but only the calling thread: other threads are not run- ning in the child process. The mutexes are not usable after the !fork! and must be initialized with |pthread_mutex_init| in the child process. This is a limitation of the current implementation and might or might not be present in future versions. I believe a while back I wondered if we might have trouble with pthreads and fork unless we were very careful, and I'm beginning to wonder again. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
