>Assuming you don't see anything amiss, perhaps I'll include this: [patch]
While I’m not familiar with how ‘dynwind’ is to be used from C, if the dynwind means what I’d expect it to mean, then this would Ensure the mutex is unlocked. But, it has another problem: deadlocking, for some uses of asyncs. • (Assuming the mutex is non-reentrant, and no async blocking) Suppose there is a queued async. Since the SCM_SYSCALL is between the locks, then the async is run with the misc mutex locked. Now, this async may choose to call ttyname, so now it’s taking the misc lock from _inside_ the misc lock. Which won’t work, since the mutex is non-reentrant. (The async doesn’t need to call ttyname per se, calling anything that also locks scm_i_misc_mutex_lock would be sufficient.) • (Reentrant mutex case, less realistic) The async could very well send some message to another thread and wait for a response. If that other, to process that message, invokes ttyname (or, again, another procedure taking the lock), you have a deadlock situation. • (More plausible situation, but a long wait instead of a real deadlock): The async needoes some intense calculations, or does something else that simply takes a long while. During this time, the scm_i_misc_mutex is locked, so other threads that want to use ttyname can’t progress for a long duration! The variant of the SCM_SYSCALL loop I provided, avoids these issues. Best regards, Maxime Devos
