> -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
> -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
s,
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 th
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 c
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_SOURCE is d
> -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()
>
>>
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() and pthr
> -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()
> han
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
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
>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 pth
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
(), but are still concerned about
third-party libraries.
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
16 matches
Mail list logo
