Re: A question on file flags after fork

2020-01-13 Thread Shware Systems
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. Chang

Re: A question on file flags after fork

2020-01-13 Thread Ronald F. Guilmette
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 ot

Re: A question on file flags after fork

2020-01-13 Thread Ronald F. Guilmette
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 be

Austin Group teleconference +1 888 974 9888 PIN 618 156 403

2020-01-13 Thread Single UNIX Specification
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 RRULE:FREQ=YE

Re: A question on file flags after fork

2020-01-13 Thread Danny Niu
"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 development

RE: A question on file flags after fork

2020-01-13 Thread Shware Systems
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

Re: A question on file flags after fork

2020-01-13 Thread Ronald F. Guilmette
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 supp

Re: A question on file flags after fork

2020-01-13 Thread Danny Niu
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 dif

A question on file flags after fork

2020-01-13 Thread Ronald F. Guilmette
Greetings all. This is my first post here and I hope you will all be kind in light of that. I need to pose a question of interpretation. While developing some C code recently, and testing that, I came upon a VERY surprising and unexpected result. It appears that various flavors of *NIX are in a

[1003.1(2008)/Issue 7 0000411]: adding atomic FD_CLOEXEC support

2020-01-13 Thread Austin Group Bug Tracker
The following issue has been set as RELATED TO issue 0001318. == http://austingroupbugs.net/view.php?id=411 == Reported By:eblake Assigned To

[1003.1(2016)/Issue7+TC2 0001318]: Define close-on-fork flag

2020-01-13 Thread Austin Group Bug Tracker
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1318 == Reported By:nate_karstens Assigned To:

[1003.1(2016)/Issue7+TC2 0001318]: Define close-on-fork flag

2020-01-13 Thread Austin Group Bug Tracker
The following issue has been set as RELATED TO issue 411. == http://austingroupbugs.net/view.php?id=1318 == Reported By:nate_karstens Ass

RE: system() and pthread_atfork()

2020-01-13 Thread Karstens, Nate
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 case:

Re: system() and pthread_atfork()

2020-01-13 Thread Robert Elz
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) POSIX

RE: system() and pthread_atfork()

2020-01-13 Thread Schwarz, Konrad
> -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 addr

[1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make

2020-01-13 Thread Austin Group Bug Tracker
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=514 == Reported By:dwheeler Assigned To:ajosey

[1003.1(2008)/Issue 7 0000514]: Enhance internal macros in make

2020-01-13 Thread Austin Group Bug Tracker
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=514 == Reported By:dwheeler Assigned To:ajosey