lkml.org 
[lkml]   [2010]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 00/11] sched: CFS low-latency features
    * Thomas Gleixner (tglx@linutronix.de) wrote:
    > On Thu, 26 Aug 2010, Thomas Gleixner wrote:
    > > On Thu, 26 Aug 2010, Peter Zijlstra wrote:
    > > >
    > > > Fudging fork seems dubious at best, it seems generated by the use of
    > > > timer_create(.evp->sigev_notify = SIGEV_THREAD), which is a really
    > > > broken thing to do, it has very ill defined semantics and is utterly
    > > > unable to properly cope with error cases. Furthermore its trivial to
    > > > actually correctly implement the desired behaviour, so I'm really
    > > > skeptical on this front; friends don't let friends use SIGEV_THREAD.
    > >
    > > SIGEV_THREAD is the best proof that the whole posix timer interface
    > > was comitte[e]d under the influence of not to be revealed
    > > mind-altering substances.
    > >
    > > I completely object to add timer specific wakeup magic and support for
    > > braindead fork orgies to the kernel proper. All that mess can be fixed
    > > in user space by using sensible functionality.
    > >
    > > Providing support for misdesigned crap just for POSIX compliance
    > > reasons and to make some of the blind abusers of that very same crap
    > > happy would be a completely stupid decision.
    > >
    > > In fact that would make a brilliant precedence case for forcing the
    > > kernel to solve user space madness at the expense of kernel
    > > complexity. If we follow down that road we get requests for extra
    > > functionality for AIO, networking and whatever in a split second with
    > > no real good reason to reject them anymore.
    >
    > I really risked eye cancer and digged into the glibc code.
    >
    > /* There is not much we can do if the allocation fails. */
    > (void) pthread_create (&th, &tk->attr, timer_sigev_thread, td);
    >
    > So if the helper thread which gets the signal fails to create the
    > thread then everything is toast.
    >
    > What about fixing the f*cked up glibc implementation in the first place
    > instead of fiddling in the kernel to support this utter madness?
    >
    > WTF can't the damned delivery thread not be created when timer_create
    > is called and the signal be delivered to that very thread directly via
    > SIGEV_THREAD_ID ?

    Yeah, that sounds exactly like what I proposed about an hour ago on IRC ;) I'm
    pretty sure that would work.

    The only thing we might have to be careful about is what happens if the timer
    re-fires before the thread completes its execution. We might want to let the
    signal handler detect these overruns somehow.

    Thanks,

    Mathieu

    >
    > Thanks,
    >
    > tglx

    --
    Mathieu Desnoyers
    Operating System Efficiency R&D Consultant
    EfficiOS Inc.
    http://www.efficios.com


    \
     
     \ /
      Last update: 2010-08-27 01:11    [W:7.452 / U:0.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site