diff options
author | Bharath Ramesh <bramesh@vt.edu> | 2005-04-16 15:25:41 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 15:25:41 -0700 |
commit | fc9c9ab22d5650977c417ef2032d02f455011b23 (patch) | |
tree | 27f9827f559cb732c78bb713e097c8a023e76768 /fs/ntfs | |
parent | 4a534f93b371e8e6e87ae302757365f0f583e06b (diff) |
[PATCH] AYSNC IO using singals other than SIGIO
A question on sigwaitinfo based IO mechanism in multithreaded applications.
I am trying to use RT signals to notify me of IO events using RT signals
instead of SIGIO in a multithreaded applications. I noticed that there was
some discussion on lkml during november 1999 with the subject of the
discussion as "Signal driven IO". In the thread I noticed that RT signals
were being delivered to the worker thread. I am running 2.6.10 kernel and
I am trying to use the very same mechanism and I find that only SIGIO being
propogated to the worker threads and RT signals only being propogated to
the main thread and not the worker threads where I actually want them to be
propogated too. On further inspection I found that the following patch
which I have attached solves the problem.
I am not sure if this is a bug or feature in the kernel.
Roland McGrath <roland@redhat.com> said:
This relates only to fcntl F_SETSIG, which is a Linux extension. So there is
no POSIX issue. When changing various things like the normal SIGIO signalling
to do group signals, I was concerned strictly with the POSIX semantics and
generally avoided touching things in the domain of Linux inventions. That's
why I didn't change this when I changed the call right next to it. There is
no reason I can see that F_SETSIG-requested signals shouldn't use a group
signal like normal SIGIO does. I'm happy to ACK this patch, there is nothing
wrong with its change to the semantics in my book. But neither POSIX nor I
care a whit what F_SETSIG does.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/ntfs')
0 files changed, 0 insertions, 0 deletions