01 May, 2005

1 commit


17 Apr, 2005

2 commits

  • 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 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
    Signed-off-by: Linus Torvalds

    Bharath Ramesh
     
  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds