I don't blame you either; I've always preferred file handle to file descriptor,
for that reason. As it is, the full list of flags is part of open(); fcntl only
has FD_NONBLOCK because this is the only flag considered safe to modify while a
file is open, however many times it's referenced.
In message ,
Danny Niu wrote:
>Anyway, this mailing list should focus on **standard development**,
>questions like this of yours should go to places like unix.stackexchange.com.
I can only thank you for your kindness, grace, generosity, and understanding.
I'm sure that these will all inspire
In message <1676199645.11146898.1578981958...@mail.yahoo.com>,
Shware Systems wrote:
>Short answer, because both file descriptors reference the same file
>description...
OK. I see where I took a wrong turn now, however I must say that I
cannot blame myself for having done so. The language
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:20120311T02
"File Descriptor" and "Open File Description" are in section 3 "Definitions" of
the "Base Definitions" volume,
As to the one "Close-On-Exec" flag, you can Ctrl-F "FD_CLOEXEC" in the
header and you'll see it's the only one listed.
Anyway, this mailing list should focus on **standard
Short answer, because both file descriptors reference the same file
description, ala a dup() being called, the SETFD modifying that description is
visible in both processes through that file descriptor. A reopen() that
attaches the reference in the child to a new description is needed for the
In message ,
Danny Niu wrote:
>To a process, a "file descriptor" is a pointer to the "open file description"
>in
>the kernel-administered memory space/range. The two are related, but have
>different set of flags.
Can you point to specific passages of the stadard, or draft standard, that
Hi there Ron.
I'm not a standard developer, I'm just an outsider who happens to have
Interest in the Unix standardization activities.
To a process, a "file descriptor" is a pointer to the "open file description"
in
the kernel-administered memory space/range. The two are related, but have
The following issue has been set as RELATED TO issue 0001318.
==
http://austingroupbugs.net/view.php?id=411
==
Reported By:eblake
Assigned
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1318
==
Reported By:nate_karstens
Assigned To:
The following issue has been set as RELATED TO issue 411.
==
http://austingroupbugs.net/view.php?id=1318
==
Reported By:nate_karstens
I agree with Robert's statement -- this is more of a general problem of
threaded applications and the interactions with fork & threads, which is a
POSIX issue. The networking issue provides an example of one scenario that we
saw a problem with. It could probably be made into a more general
Date:Mon, 13 Jan 2020 10:13:04 +
From:"Schwarz, Konrad"
Message-ID:
| I actually feel this problem is out-of-scope for POSIX: compliant machines
| are not supposed to dynamically change their IP addresses at run-time.
I have no idea what (if anything)
> -Original Message-
> From: Karstens, Nate
> Sent: Sunday, January 12, 2020 11:52 AM
> To: 'austin-group-l@opengroup.org'
> Subject: Re: system() and pthread_atfork()
Going back to the original problem,
> We are running Linux on an embedded system. The platform can
> change the IP
14 matches
Mail list logo
