lkml.org 
[lkml]   [2007]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0 of 4] Generic AIO by scheduling stacks
    On Sat, 3 Feb 2007, Davide Libenzi wrote:

    > > - Signals. I have no idea what behaviour we want. Help? My first guess is
    > > that we'll want signal state to be shared by fibrils by keeping it in the
    > > task_struct. If we want something like individual cancellation, we'll augment
    > > signal_pending() with some some per-fibril test which will cause it to return
    > > from TASK_INTERRUPTIBLE (the only reasonable way to implement generic
    > > cancellation, I'll argue) as it would have if a signal was pending.
    >
    > Fibril should IMO use current thread signal policies. I think a signal
    > should hit (wake) any TASK_INTERRUPTIBLE fibril, if the current thread
    > policies mandate that. I'd keep a list_head of currently scheduled-out
    > TASK_INTERRUPTIBLE fibrils, and I'd make them runnable when a signal is
    > delivered to the thread (wake_target bit #1 set to mean wake-all-interruptable-fibrils?).
    > The other thing is signal_pending(). The sigpending flag test is not going
    > to work as is (cleared at the first do_signal). Setting a bit in each
    > fibril would mean walking the whole TASK_INTERRUPTIBLE fibril list. Maybe
    > a sequential signal counter in task_struct, matched by one in the fibril.
    > A signal would increment the task_struct counter, and a fibril
    > schedule-out would save the task_struct counter to the fibril. The
    > signal_pending() for a fibril is a compare of the two. Or something
    > similar.

    Another thing linked to signals that was not talked about, is cancellation
    of an in-flight request. We want to give the ability to cancel an
    in-flight request, with something like async_cancel(cookie). In my
    userspace library I simply disable SA_RESTART of SIGUSR2, and I do a
    pthread_kill() on the thread servicing the request. But this will IMO have
    other implications (linked to signal delivery) in a kernel fibril-based
    implementation, to think about it.



    - Davide


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-02-04 21:03    [W:0.022 / U:2.316 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site