lkml.org 
[lkml]   [2004]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: For the almost 4-year anniversary: O_CLOEXEC again
    Jamie Lokier wrote:

    > Since O_CLOEXEC is non-portable, why not implement the per-thread
    > switch?
    >
    > Signal handlers that call open() will have to be aware of it, but
    > that's ok: an application will only set the switch if it knows what
    > that implies.

    It's not OK since library functions can install signal handlers and they
    need not be aware of everything the application does.

    Any globally visible change in the behavior can have negative effects.

    Yes, there are other calls but open() is far more critical since it is
    now promoted not only to an interface to actually do work. We are
    supported to read kernel and system informatino from /proc which
    requires open().

    And no, oen() is not the only signal-safe function. If you don't have
    the POSIX specs handy, look at a recent signal(2) man page which lists
    the signal-safe functions. accept(), socket() are on the list among others.

    --
    ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
    -
    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: 2005-03-22 14:02    [W:0.020 / U:3.724 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site