Re: concurrent access

[Will Lockhart <will@mvhi.com>]

M.Stein writes:
 > Hi Will,
 > On Thu, 24 Feb 2000, Will Lockhart wrote:
 > > Lets say I have two framegrabber cards (PCDig in this case) in the
 > > machine, but only one (multithreaded) process handling the images from 
 > > both cards. How do I know, when I get a SIGIO, which card generated
 > > it? Do I have to poll() the file descriptors for both cards?
 > 
 > Unfortunately, you don't know it. Poll is the right solution for one
 > process.
 >  
 > > On a similar subject, can anyone explain the interaction between
 > > signals, threads and fcntl(F_SETOWN)? According to the POSIX
 > > specification, a signal is delivered to an arbitrary thread within the 
 > > process. You can force the signal to be delivered to a specific thread 
 > > by blocking the signal in all threads, and sigwaiting for it in your
 > > signal handling thread.
 > > 
 > > However, on Linux, each thread has its own PID, so does doing a
 > > fcntl(F_SETOWN) guarantee the signal is delivered to that thread?
 > 
 > I don't have tested it, but I also understand it this way. And from the
 > point of the kernel code it have to work so.
 > 
 > Perhaps there is a mailing list for linux threads to mail to?
 > 
 > Please let me know your results, if you have tested it!

Matthias,

Actually, I currently only have one framegrabber, so I was just trying 
to write my code in a way that would work when we have two
framegrabbers. Certainly polling on one card works fine, so I imagine
it will also work OK with two.

As to the signals and threads issue, this is what I know so far:

Under Linux, each thread does indeed have its own PID. Signals can be
delivered to a specific process ID, and therefore, a signal which is
delivered to a process will be delivered to a specific thread in that
process. This is consistent with the POSIX standard, that says that
signals that are delivered to a process are delivered to an arbitrary
thread in that process. (However, this also leads to a situation where 
LinuxThreads are not POSIX compliant - the POSIX standard says that if 
a signal is delivered to a thread which is blocking that signal, but
there is another thread which is not blocking the signal, the second
thread will receive the signal. This does not happen with Linux - the
signal will simply not be delivered at in this situation).

The correct POSIX way to handle this situation is to block the signal
in all threads, then sigwait for it in a thread dedicated to catching
the signal. So I block the SIGIO signal in all my threads, create a
new thread, use fcntl to tell the driver to deliver signals to that
thread and use sigwait to wait for the signal to arrive and.... it
doesn't work :(

I've e-mailed the author of the LinuxThreads library, and explained
the problem. He thinks it ought to work, and so do I. The only
possibility, it seems to me, is that the SIGIO signal is in fact not
being delivered to the process (thread) that I've specified, but to
some other thread in the same process.

I will try strace-ing the process to see what is actually happening
with the signals.

Will

-- 
Will Lockhart, System Developer, Axiom (Cambridge) Ltd.
http://www.mvhi.com/