[lkml]   [2000]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] thread wakeup fix for 2.4.0-test7

    > _not_ aborting read() and in absence of the third thread we _do_ abort
    > read(). QED: close(dup(fd1)) changes the behaviour of program.
    > IIRC, you've agreed that it was wrong just a couple of posts upthread.

    Read is aborted as soon as file closed. File is closed,
    when nobody has access to it. While third thread holds it open,
    hothing happens. As soon as all the access points are deleted,
    file is closed.

    Alive object cannot be orphan. That's invariant to hold.

    > Yes? How about close() right _after_ read() returns? Should it
    > retroactively change the return value to -EBADF? You have the race
    > anyway.

    Moreover! If read() has some _data_ read while close() (due to race or
    due to SO_RCVLOWAT) it does not return error. It returns data
    despite of neither descriptor nor file itself exist to this time.
    It is normal.

    > Look: you are asking for completely new mechanism for aborting blocked
    > IO operations. Occam's Razor applies.

    Nope. "New" mechanism already exists, at least for sockets.
    It is shutdown(2). But it works only in Linux.

    > Arguments against that mechanism:
    > * doesn't work unless caller has all references to file at hands
    > and remembers about them.
    > * doesn't provide anything new compared to kill(2).
    > * in the case when read would succeed it introduces a new effect -
    > close(dup(fd)) changes the program behaviour.
    > What are your arguments for the inclusion of this mechanism, aside of the
    > fact that Solaris has it?

    No ones. Except for ecological ones: I prefer when children
    have parents. Orphaned files must be closed.

    What a pity, I have already used these your arguments. 8)

    Only third one sounds different: not close(dup(fd)) changes
    behaviour of program, but close() in thread is poorly defined
    and its result is unpredictable, when more than one thread use
    this descriptor. So, you (not you, but that poor programmer 8))
    are fool, we are all in the white. 8)

    The problem is that it is unpredictable in theory.
    In practice kernel is able (and does in other unces) predictably
    not to lose files and threads and not to hang in sleeps.

    > former to Linux. Question: what for?

    Do you want really honest answer? Keep it!

    Because I am tired to prove that it is not a bug in TCP. 8)

    As you can guess, the problem is really essential only for TCP,
    because it has to make an active action (FIN) to start close
    and because it has another syscalls (connect, accept), which
    hang really frequently. And because no OSes provide tools to do this,
    so that people learned and use close().

    Also, because it is easy to argue to you (and even to Linus 8)),
    I know that after some sleep you will calm down, understand my point,
    switch to something constructive, and reject or accept it.
    But it is impossible to argue to guy, who is porting his (bogus) software
    from nt,solaris,dux in hope to make some more money (or PR, if he is more
    clever) on linux boom and sees that his app has no chances to work. 8)
    If you tell hime about kill(), he will kill you; he learned
    MT programming exactly to forget about signals forever. 8)

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

     \ /
      Last update: 2005-03-22 12:38    [W:0.050 / U:0.032 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site