Re: A question on file flags after fork
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. Changing from O_RDONLY to O_APPEND on the fly can be problematic to applications using pread(), for example, to access records from a database in parallel. On Tuesday, January 14, 2020 Ronald F. Guilmette wrote: 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 being used for the base concepts here is exceptionally stilted. We have -descriptors- and then we have file -descriptions-. I get it now, but I cannot help but wish that the original drafters, way back when, had elected to be a bit less clever and bit more obvious in their coinage of the relevant terminology here. The term "file desctriptor" was grandfathered in from the ancient times of UNIX. So that was cast in stone and could not be reasonably changed. But I would have been a LOT happier if those standard drafters, back in the day, had elected to call what is apparently now called a "file description" something else... a "purple aardvark" or basically anything other that the thing they finally settled on, which is extraordinarily subject to misinterpretation, being as it is, so close to the term "file descriptor". Moving ahead, now that my misreading has been corrected, I'd like to just throw out a trial balloon and note that it would be pragmatically useful to provide some attributes that are currently associated only with "file descriptions" also for file descriptors. O_NONBLOCK is the one that is most immediately apparent to me, but I can readily imagine usefulness also for permitting things like O_APPEND and even O_RDONLY and O_WRONLY to be applied selectively to individual file descriptors, rather than to (shared) file descriptions. I will happily elaborate on a real-world scenario in which this would have been most useful to have, if anyone is interested, and also the ugly ccode contortions that had to be applied in order to work-around this particular non- feature, which I am now aware is 100% standard conformant. Regards, rfg
Re: A question on file flags after fork
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 others more worthy than myself to wish to contribute meaningfully to the ongoing standardization effort. Regards, rfg
Re: A question on file flags after fork
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 being used for the base concepts here is exceptionally stilted. We have -descriptors- and then we have file -descriptions-. I get it now, but I cannot help but wish that the original drafters, way back when, had elected to be a bit less clever and bit more obvious in their coinage of the relevant terminology here. The term "file desctriptor" was grandfathered in from the ancient times of UNIX. So that was cast in stone and could not be reasonably changed. But I would have been a LOT happier if those standard drafters, back in the day, had elected to call what is apparently now called a "file description" something else... a "purple aardvark" or basically anything other that the thing they finally settled on, which is extraordinarily subject to misinterpretation, being as it is, so close to the term "file descriptor". Moving ahead, now that my misreading has been corrected, I'd like to just throw out a trial balloon and note that it would be pragmatically useful to provide some attributes that are currently associated only with "file descriptions" also for file descriptors. O_NONBLOCK is the one that is most immediately apparent to me, but I can readily imagine usefulness also for permitting things like O_APPEND and even O_RDONLY and O_WRONLY to be applied selectively to individual file descriptors, rather than to (shared) file descriptions. I will happily elaborate on a real-world scenario in which this would have been most useful to have, if anyone is interested, and also the ugly ccode contortions that had to be applied in order to work-around this particular non- feature, which I am now aware is 100% standard conformant. Regards, rfg
Austin Group teleconference +1 888 974 9888 PIN 618 156 403
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=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:20121104T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:5e1d5ca1c0...@opengroup.org DTSTAMP:20200114T061601Z ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org CREATED:20200114T00Z DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 20-Jan-2020 at 11: 00 America/New_York\nDuration: 1.00 hours\nURL: https://collaboration.open group.org/platform/single_unix_specification/events.php\n\n** All calls ar e anchored on US time **\n\nTopic: Austin Group teleconference\n-- -\nAudio conference informatio n\n---\n\nYou are invi ted to a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, iOS or Android: https://logitech.zoom.us/j/618156403\n \nor join by phone: \nUS: 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n \nOther international numbers available here:\nhttps://zoom.us/u/adlvrb8IL j\n \nMeeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\n Dial: 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID: 618 156 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n \nOr iPhone one-tap (US Toll): +16699006833\,618156403# or +16465588656\, 618156403#\n\nAll Austin Group participants are most welcome to join the c all.\nThe call will last for 60 minutes.\n\n\nAn etherpad is usually up fo r a meeting\, with a URL using the date format as below:\n\nhttp://posix.r hansen.org/p/20xx-mm-dd\nusername=posix password=2115756#\n\nBug reports a re available at:\nhttp://www.austingroupbugs.net\n DTSTART;TZID=America/New_York:20200120T11 DURATION:PT1H0M0S LAST-MODIFIED:20200114T011601Z ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403 TRANSP:OPAQUE URL:https://collaboration.opengroup.org/platform/single_unix_specification/ events.php X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-VISIBILITY:40 X-JOINBEFORE:5 X-CATEGORY:Teleconference X-PLATO-SITE:Single UNIX Specification X-PLATO-SITEID:136 END:VEVENT END:VCALENDAR meeting.ics Description: application/ics
Re: A question on file flags after fork
"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**, questions like this of yours should go to places like unix.stackexchange.com. 在 2020-01-14 14:07:23，“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 support either of those assertions? >The currently (only) defined flag for "file descriptor" is the "close-on-exec" >flag where as there's many more flags for the "open file description". Same question. Can you quote chapter and verse from the actual standard, or draft standard, to supoprt what you have asserted? >You can find out more about the 2 concepts in the base volume. Hope this helps. Not really. But I appreciate the effort. Regards, rfg
RE: A question on file flags after fork
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 operation to be independant of the parent. The copy mentioned is of the fd values being "in use", that's all. On Monday, January 13, 2020 Ronald F. Guilmette wrote: 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 agreement that after a fork, the set of flag bits (e.g. O_NONBLOCK) that are associated with any specific file descriptor that was open prior to the fork will, after the fork, exist only as a single shared set of flag bits... *not* one copy for the parent and a separate set for the child. My reading of both the old and faded hardcopy of the 1993 POSIX API standard that I have here, as well as the newer draft that Mr. Andrew Josey was kind enough to point me at today strongly suggest to me that the implementations I have tested (Linux + FreeBSD) are not conforming to what is actually on the printed page, either in the 1993 IEEE standard or in the newer 2018 draft that I am looking at now. I have come here to solicit opinions on this point. I have prepared two short example programs exclusively to illustrate the issue. The first illustrates the issue with respect to ordinary file descriptors, while the second does so with respect to message queues. (But the results, when tested against real current implementations, are identical for both example programs and thus perfectly consistant with one another, shoing that wether this behavior if confirmant to the standard or not for both types of descriptors, at least there is consistancy. :-) These two short example programs may be found at the following links: https://pastebin.com/raw/AKuWJvyS https://pastebin.com/raw/KdhKt2Ya In both cases, the programs end up printing: O_NONBLOCK magically unset in parent This occurs in both cases shortly after the recently forked child processes have expressely and deliberately un-set the O_NONBLOCK flag for a file descriptor that they have inherited a copy of at the time of the preceeding fork. To me, this outcome was beyond surprising, and in conversations with a dear friend I likened it to the infamous "spooky action at a distance" of quantum mechanics, which none other than Albert Einstein famously found so troubling. I am no Einstein by any streatch of the imagination, but like him I also find this "spooky action at a distance" most disconcerting and also inexplicable. How can diddling the flags for one file descriptor cause the flags of a different file descriptor to magically change also? At the present moment this still makes no good sense to me, and as I have said, it appears to me to be inconsistant with the plain language of the standard as written. I can and will expound upon this point, as may be necessary, but for now I would prefer to just get some feedback from you folks. I am fairly thick skinned, so by all means, please feel free to tell me if you think I'm just crazy, and if in fact the standard does not mean what it says when it says "The child process shall have its own copy of the parent's file descriptors." Thank you all for your attention. Regards, rfg
Re: A question on file flags after fork
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 support either of those assertions? >The currently (only) defined flag for "file descriptor" is the "close-on-exec" >flag where as there's many more flags for the "open file description". Same question. Can you quote chapter and verse from the actual standard, or draft standard, to supoprt what you have asserted? >You can find out more about the 2 concepts in the base volume. Hope this >helps. Not really. But I appreciate the effort. Regards, rfg
Re: A question on file flags after fork
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 different set of flags. The currently (only) defined flag for "file descriptor" is the "close-on-exec" flag, where as there's many more flags for the "open file description". You can find out more about the 2 concepts in the base volume. Hope this helps. 在 2020-01-14 12:27:30，“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 agreement that after a fork, the set of flag bits (e.g. O_NONBLOCK) that are associated with any specific file descriptor that was open prior to the fork will, after the fork, exist only as a single shared set of flag bits... *not* one copy for the parent and a separate set for the child. My reading of both the old and faded hardcopy of the 1993 POSIX API standard that I have here, as well as the newer draft that Mr. Andrew Josey was kind enough to point me at today strongly suggest to me that the implementations I have tested (Linux + FreeBSD) are not conforming to what is actually on the printed page, either in the 1993 IEEE standard or in the newer 2018 draft that I am looking at now. I have come here to solicit opinions on this point. I have prepared two short example programs exclusively to illustrate the issue. The first illustrates the issue with respect to ordinary file descriptors, while the second does so with respect to message queues. (But the results, when tested against real current implementations, are identical for both example programs and thus perfectly consistant with one another, shoing that wether this behavior if confirmant to the standard or not for both types of descriptors, at least there is consistancy. :-) These two short example programs may be found at the following links: https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fraw%2FAKuWJvySdata=02%7C01%7C%7C646865780eaf4d849a7308d798aa1073%7C84df9e7fe9f640afb435%7C1%7C0%7C637145728496131504sdata=fBbIB618OP%2F5l%2F9HOf80YIErBI8yW4eWNlL%2BWx%2F57wI%3Dreserved=0 https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fraw%2FKdhKt2Yadata=02%7C01%7C%7C646865780eaf4d849a7308d798aa1073%7C84df9e7fe9f640afb435%7C1%7C0%7C637145728496131504sdata=Z1jaIkYhoSt8m28S4i4vCCzgEjBOZScCAOBTfjaPJiU%3Dreserved=0 In both cases, the programs end up printing: O_NONBLOCK magically unset in parent This occurs in both cases shortly after the recently forked child processes have expressely and deliberately un-set the O_NONBLOCK flag for a file descriptor that they have inherited a copy of at the time of the preceeding fork. To me, this outcome was beyond surprising, and in conversations with a dear friend I likened it to the infamous "spooky action at a distance" of quantum mechanics, which none other than Albert Einstein famously found so troubling. I am no Einstein by any streatch of the imagination, but like him I also find this "spooky action at a distance" most disconcerting and also inexplicable. How can diddling the flags for one file descriptor cause the flags of a different file descriptor to magically change also? At the present moment this still makes no good sense to me, and as I have said, it appears to me to be inconsistant with the plain language of the standard as written. I can and will expound upon this point, as may be necessary, but for now I would prefer to just get some feedback from you folks. I am fairly thick skinned, so by all means, please feel free to tell me if you think I'm just crazy, and if in fact the standard does not mean what it says when it says "The child process shall have its own copy of the parent's file descriptors." Thank you all for your attention. Regards, rfg
[1003.1(2008)/Issue 7 0000411]: adding atomic FD_CLOEXEC support
The following issue has been set as RELATED TO issue 0001318. == http://austingroupbugs.net/view.php?id=411 == Reported By:eblake Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 411 Category: System Interfaces Type: Enhancement Request Severity: Objection Priority: normal Status: Resolved Name: Eric Blake Organization: Red Hat User Reference: ebb.cloexec Section:various - see desired action Page Number:various - see desired action Line Number:various - see desired action Interp Status: --- Final Accepted Text:See desired action section in attached file bug411_atomic_CLOEXEC.pdf 2014-05-03 16:45 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2011-04-20 17:01 UTC Last Modified: 2018-09-10 16:32 UTC == Summary:adding atomic FD_CLOEXEC support == Relationships ID Summary -- related to 149 Add fdwalk system interface related to 368 Hidden file descriptors should be requi... related to 0001208 calling chdir as part of posix_spawn parent of 598 OH shading and new interfaces parent of 833 SOCK_* flags in getaddrinfo hints-a... has duplicate 331 Add 'x' mode to fopen and freopen to fo... related to 456 mandate binary mode of fmemopen related to 590 dup2 and signals related to 591 No reason for OH margins in the synopse... related to 593 posix_typed_mem_open requires the use o... related to 662 Clarify or add file descriptor preserva... related to 0001302 Alignment with C17 related to 0001318 Define close-on-fork flag == Issue History Date ModifiedUsername FieldChange == 2011-04-20 17:01 eblake New Issue 2011-04-20 17:01 eblake Status New => Under Review 2011-04-20 17:01 eblake Assigned To => ajosey 2011-04-20 17:01 eblake Name => Eric Blake 2011-04-20 17:01 eblake Organization => Red Hat 2011-04-20 17:01 eblake User Reference=> ebb.cloexec 2011-04-20 17:01 eblake Section => various - see desired action 2011-04-20 17:01 eblake Page Number => various - see desired action 2011-04-20 17:01 eblake Line Number => various - see desired action 2011-04-20 17:01 eblake Interp Status => --- 2011-04-20 17:02 eblake Tag Attached: issue8 2011-04-20 17:03 eblake Relationship added related to 149 2011-04-20 17:03 eblake Relationship added related to 368 2011-04-28 16:21 eblake Description Updated 2011-04-28 16:21 eblake Desired Action Updated 2011-04-28 16:23 eblake Note Added: 773 2011-04-28 18:41 eblake Note Added: 774 2011-05-03 11:04 drepperNote Added: 776 2011-06-02 19:13 eblake Relationship added related to 456 2011-08-03 21:38 eblake Note Added: 917 2011-08-04 15:42 nick Final Accepted Text => See http://austingroupbugs.net/view.php?id=411#c917 2011-08-04 15:42 nick Status Under Review => Resolution Proposed 2011-08-04 15:42 nick Resolution Open => Accepted As Marked 2011-08-04 15:44 nick Status Resolution Proposed => Resolved 2011-08-15 12:10 eblake Note Edited: 917 2011-09-22 16:21 eblake Relationship added related to 331 2011-09-22 16:22 nick Relationship replacedhas duplicate 331 2012-06-26 23:15 eblake Relationship added
[1003.1(2016)/Issue7+TC2 0001318]: Define close-on-fork flag
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1318 == Reported By:nate_karstens Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1318 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Nate Karstens Organization: Garmin User Reference: Section:fcntl, open, socket Page Number:Unknown Line Number:Unknown Interp Status: --- Final Accepted Text: == Date Submitted: 2020-01-12 10:50 UTC Last Modified: 2020-01-13 16:38 UTC == Summary:Define close-on-fork flag == Relationships ID Summary -- related to 411 adding atomic FD_CLOEXEC support == -- (0004728) eblake (manager) - 2020-01-13 16:38 http://austingroupbugs.net/view.php?id=1318#c4728 -- Standardization of dup3() and SOCK_CLOEXEC is already the subject of http://austingroupbugs.net/view.php?id=411 Issue History Date ModifiedUsername FieldChange == 2020-01-12 10:50 nate_karstens New Issue 2020-01-12 10:50 nate_karstens Name => Nate Karstens 2020-01-12 10:50 nate_karstens Organization => Garmin 2020-01-12 10:50 nate_karstens Section => fcntl, open, socket 2020-01-12 10:50 nate_karstens Page Number => Unknown 2020-01-12 10:50 nate_karstens Line Number => Unknown 2020-01-13 07:28 kreNote Added: 0004725 2020-01-13 16:37 eblake Relationship added related to 411 2020-01-13 16:38 eblake Note Added: 0004728 ==
[1003.1(2016)/Issue7+TC2 0001318]: Define close-on-fork flag
The following issue has been set as RELATED TO issue 411. == http://austingroupbugs.net/view.php?id=1318 == Reported By:nate_karstens Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1318 Category: System Interfaces Type: Enhancement Request Severity: Comment Priority: normal Status: New Name: Nate Karstens Organization: Garmin User Reference: Section:fcntl, open, socket Page Number:Unknown Line Number:Unknown Interp Status: --- Final Accepted Text: == Date Submitted: 2020-01-12 10:50 UTC Last Modified: 2020-01-13 16:37 UTC == Summary:Define close-on-fork flag == Relationships ID Summary -- related to 411 adding atomic FD_CLOEXEC support == Issue History Date ModifiedUsername FieldChange == 2020-01-12 10:50 nate_karstens New Issue 2020-01-12 10:50 nate_karstens Name => Nate Karstens 2020-01-12 10:50 nate_karstens Organization => Garmin 2020-01-12 10:50 nate_karstens Section => fcntl, open, socket 2020-01-12 10:50 nate_karstens Page Number => Unknown 2020-01-12 10:50 nate_karstens Line Number => Unknown 2020-01-13 07:28 kreNote Added: 0004725 2020-01-13 16:37 eblake Relationship added related to 411 ==
RE: system() and pthread_atfork()
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: 1) Application acquires exclusive access to a system resource 2) Application forks 3) Application tries to release & re-acquire access to that resource; there is a race between the exec() in the child process (releasing the child's access) and the parent re-acquiring access Thanks, Nate -Original Message- From: Robert Elz Sent: Monday, January 13, 2020 6:43 AM To: Schwarz, Konrad Cc: Karstens, Nate ; austin-group-l@opengroup.org Subject: Re: system() and pthread_atfork() CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe. 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 says about IP networking requirements, but I'd expect not much, but that (if it were stated somewhere) would be an error. Staticaally assigned IPv4 (or even IPv6) addresses do not tend to change much, but just about no-one uses those any more. If you obtain your address (v4 or v6) via DHCP, then when your host goes to renew the lease, the server can decline, and instruct you (your DHCP client) to request a new address, at which point it can give out whatever is appropriate, not necessarily even slightly related to what was there before. For v6 without DHCP, using stateless autoconfiguration, the router advertises a (or more than one) local network prefix, with a lifetime, and can alter that prefix whenever it is required. One of the real problems with networking in the 80's was dealing with client networks that needed to be renumbered - the workload for any reasonable sized network was prohibitive. One of v6's goals was to defeat that problem (it wasn't only about more addresses). In the meantime v4 has switched away from static configs (/etc/hosts or the equivalent) or from BOOTP for hosts without static storage, and to DHCP (where the 'D' really does mean dynamic) which some v6 sites also use (some odd notion of the network managers actually being able to control things that way, which is incorrect, but gives the net admins a warm fuzzy feeling, and it is what they have become used to with v4). All that said, I agree that anything related to this issue would be out of scope for POSIX, but the more general problem of threaded applications (which it must be, that's the only way that the process can be simultaneously closing & opening sockets, while also, unknown to itself, also forking) and the interactions wrt fork & threads, is a POSIX issue. That the actual problem is networking related is just a side issue, I believe. kre (IAB member during the period all this network transition started). CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
Re: system() and pthread_atfork()
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 says about IP networking requirements, but I'd expect not much, but that (if it were stated somewhere) would be an error. Staticaally assigned IPv4 (or even IPv6) addresses do not tend to change much, but just about no-one uses those any more. If you obtain your address (v4 or v6) via DHCP, then when your host goes to renew the lease, the server can decline, and instruct you (your DHCP client) to request a new address, at which point it can give out whatever is appropriate, not necessarily even slightly related to what was there before. For v6 without DHCP, using stateless autoconfiguration, the router advertises a (or more than one) local network prefix, with a lifetime, and can alter that prefix whenever it is required. One of the real problems with networking in the 80's was dealing with client networks that needed to be renumbered - the workload for any reasonable sized network was prohibitive. One of v6's goals was to defeat that problem (it wasn't only about more addresses). In the meantime v4 has switched away from static configs (/etc/hosts or the equivalent) or from BOOTP for hosts without static storage, and to DHCP (where the 'D' really does mean dynamic) which some v6 sites also use (some odd notion of the network managers actually being able to control things that way, which is incorrect, but gives the net admins a warm fuzzy feeling, and it is what they have become used to with v4). All that said, I agree that anything related to this issue would be out of scope for POSIX, but the more general problem of threaded applications (which it must be, that's the only way that the process can be simultaneously closing & opening sockets, while also, unknown to itself, also forking) and the interactions wrt fork & threads, is a POSIX issue. That the actual problem is networking related is just a side issue, I believe. kre (IAB member during the period all this network transition started).
RE: system() and pthread_atfork()
> -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 address either according to a proprietary negotiation scheme > or a manual setting. The application uses netlink to listen for IP address > changes; > when this occurs the application closes all of its sockets and re-opens them > using the new address. > > A problem can occur if the application is simultaneously fork/exec-ing a new > process. > The parent process attempts to bind a new socket to a port that it had > previously > bound to (before the IP address change), only to fail because the child > process > continues to hold a socket bound to that port. 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. Even if we accept this premise, I'm not sure I understand the problem: suppose, on the bound socket, you used the specific IP address; then, when switching to the new address, you could simply create a new socket using the new specific address. Since port numbers are local to IP addresses, this should not create a conflict. (The process should close the old socket to conserve file descriptors). On the other hand, if you were using INADDR_ANY, why not simply leave the socket open? I would expect a machine that allows dynamic changes to the supported internet addresses to route new connection requests to pre-existing sockets bound to INADDR_ANY.
