> -Original Message-
> From: Robert Elz
> Sent: Tuesday, January 14, 2020 11:35 AM
> To: Schwarz, Konrad (CT RDA IOT SES-DE)
> Cc: nate.karst...@garmin.com; austin-group-l@opengroup.org
> Subject: Re: system() and pthread_atfork()
> | The point I was trying to m
Date:Tue, 14 Jan 2020 08:35:14 +
From:"Schwarz, Konrad"
Message-ID:
| Captain Obvious here:
| A minimal quality of implementation attribute for DHCP daemons is for
| these addresses to remain fixed for as long as possible.
Yes, address stability is useful
> -Original Message-
> From: Robert Elz
> Sent: Monday, January 13, 2020 1:43 PM
> To: Schwarz, Konrad (CT RDA IOT SES-DE)
> Cc: nate.karst...@garmin.com; austin-group-l@opengroup.org
> Subject: Re: system() and pthread_atfork()
>
> Date:Mon, 13
ess
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 tr
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
> -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
Subject: Re: system() and pthread_atfork()
Thanks to everyone for the great responses! Below are some notes/discussion on
the various replies I've seen:
> If it's supposed to behave as if fork() has been called, this implicitly
> includes calling atfork handlers when POSIX_C_S
> -Original Message-
> From: Matthew Dempsky
> Sent: Friday, January 3, 2020 2:27 AM
> To: Schwarz, Konrad (CT RDA IOT SES-DE)
> Cc: Karstens, Nate ; austin-group-l@opengroup.org
> Subject: Re: system() and pthread_atfork()
>
> On Thu, Jan 2, 2020 at
> From: Schwarz, Konrad <mailto:konrad.schw...@siemens.com>
> Sent: Thursday, January 2, 2020 5:00 AM
> To: Karstens, Nate <mailto:nate.karst...@garmin.com>;
> mailto:austin-group-l@opengroup.org
> Subject: [EXTERNAL] RE: system() and pthread_atfork()
>
>>
n be altered to call your pthread_atfork()
handlers as you see fit, without regard to what the platform's implementation
might, or might not, do.
From: Schwarz, Konrad
Sent: Thursday, January 2, 2020 5:00 AM
To: Karstens, Nate ; austin-group-l@opengroup.org
Subject: [EXTERNAL] RE: system(
> -Original Message-
> From: Karstens, Nate
> Sent: Thursday, December 19, 2019 12:26 AM
> To: austin-group-l@opengroup.org
> Subject: system() and pthread_atfork()
>
> The current definition of system() does not define if the pthread_atfork()
> handlers a
On 12/20/19 2:40 PM, Karstens, Nate wrote:
That might be, but it would be good to document the tradeoffs associated with
that efficiency. Even better would be to come up with a mechanism to avoid it
entirely. If requiring pthread_atfork() handlers to execute is not an option,
then maybe a file
Thanks to everyone for the great responses! Below are some notes/discussion on
the various replies I've seen:
> If it's supposed to behave as if fork() has been called, this implicitly
> includes calling atfork handlers when POSIX_C_SOURCE is defined...
Regarding glibc, I'm not sure the POSIX_C
>This seems like a scenario where you would want system() to require
>pthread_atfork() handlers to be called. Aside from that, it seems somewhat
>contradictory that system() "shall behave as if a child process were created
>using fork()..." but it is undefined if pthread_atfork() handlers are
Hello.
Karstens, Nate wrote in :
|The current definition of system() does not define if the pthread_atfork() \
...
No head to think about that but..
...
|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 chan
Greetings,
The current definition of system() does not define if the pthread_atfork()
handlers are called. We ran into a scenario where this caused a problem and
wanted to share it with the mailing list to better understand why those
handlers are not required and get some advice on how best to
16 matches
Mail list logo