[Spread-users] Question about thread-safety

[John Schultz]

> My concern was handling multithreaded _AND_ multiprocess applications 
> equally well.  So, the implementation must keep in mind that there are 
> subtleties with fork() duplicating the internal table/hash you use for 
> managing the contexts of user sessions.
> 
> The implementation needs to have a graceful way of deallocating a 
> session in a child process that inherited it without wanting it.


I was thinking of something along the lines of exporting SP_kill.

> Since we are about 20 minutes apart, maybe we should talk about this in 
> person.  [I certainly hope] we can come up with a better solution 
> together than either of us alone.


I would actually like that very much. I still have not convinced myself 
that I've completely solved the multi-thread FD reuse race condition.

I realized that using a mutex to protect the close'ing of a file 
descriptor has a major problem: threads blocked in recv or send can 
block forever, therefore the only way to wake such a thread (that I 
know) is to close the file descriptor on which it is blocked. 
Unfortunately, this gets us right back to where we started -- the race 
condition still exists.

This seems to me to be a major/fundamental problem with multi-threaded 
programming on Linux/Unix systems -- has anyone seen this problem 
addressed in literature?

On Linux/Unix systems could we use signals to break the blocked threads 
out of the recv/send call?  Can we signal specific threads?

-- 
John Schultz
Co-Founder, Lead Engineer
D-Fusion, Inc. (http://www.d-fusion.net)
Phn: 443-838-2200 Fax: 707-885-1055