[lkml]   [2002]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] compatibility syscall layer (lets try again)

    On Wed, 4 Dec 2002, Jim Houston wrote:
    > Agreed! In my alternative version of the Posix timers patch, I avoid
    > calling do_signal() from clock_nanosleep by using a variant of the
    > existing ERESTARTNOHAND mechanism. The problem I ran into was that I
    > could not tell on entry to clock_nanosleep if it was a new call or
    > an old one being restarted.

    Restarting has other problems too, namely how to save off the partial

    > I solved this by adding a new
    > ERESTARTNANOSLP error code and making a small change in do_signal().
    > The handling of ERESTARTNANOSLP is the same as ERESTARTNOHAND but also
    > sets a new flag in the task_struct before restarting the system call.

    The problem I see with this is that the signal handler can do a
    "siglongjump()" out of the regular path, and the next system call may well
    be a _new_ nanosleep() that has nothing to do with the old one. And
    realizing that it's _not_ a restarted one is interesting.

    A better and more flexible approach would be to not restart the same
    system call with the same parameters, but having some way of telling
    do_signal to restart with new parameters and a new system call number.

    For example, it shouldn't be impossible to have an interface more akin to

    thread_info->restart_block.syscall = __NR_nanosleep_restart;
    thread_info->restart_block.arg0 = timeout + jiffies; /* absolute time */

    where the signal stack stuff re-writes not just eip (like the current
    restart logic does), but also rewrites the system call number and the
    argument registers.

    This way you can get a truly restartable system call, because the
    arguments really need to be fundamentally changed (the restarted system
    call had better have _absolute_ time, not relative time, since we don't
    know how much time passed before it got restarted).


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:31    [W:0.020 / U:41.620 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site