Re: static fork strerror and how they interact.

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Tue, Oct 28, 2014 at 9:01 AM, frank ernest <doark@mail.com> wrote:
> Hello, I've been reading the glibc docs and they read that the function strerror warns that when using multiple threads that the static buffer may be overwritten. At the same time I wanted to create a new thread using fork and it says thet the process it spawns _will_ have a complete copy of the parents memory space. I also thought from what I learned that declaring anything as static garentees that the said thing will not be addressable from another process.
> My question is this, if I'm correct in my deductions so far am I corretc in believing that the strerror function, after fork is used, _will_ have a _seperate_ static buffer for the newly spawned process, and so the buffer will not be accidentally overwritten?

(1) The strerror() function is not MT-Safe, use strerror_r() instead.

http://www.gnu.org/software/libc/manual/html_node/Error-Messages.html#index-strerror

(2) You should use pthread_create() to make new threads not fork().

(3) If you meant "create new process using fork", then yes, fork()
will give the child a complete copy of the parent's memory space.

(4) Declaring a global data definition as `static` will restrict the
visibility of the global to the file, other files you compile and link
with will not be able to access that global data directly. That
enforcing happens at the language level. At the runtime level you can
pass the address of that global to another function and it can use
that address to write to the global data that has file local scope.
The fork'd thread will have a copy of that data and will be able to do
what any other program could do.

(5) Yes, after the fork, the child has a copy of the entire address
space, and calling strerror() will not interact with the threads in
the parent process.

(6) WARNING: Calling fork() in a multi-threaded process forces the
child to operate in the equivalent of async-signal mode. The child may
only call async-signal safe functions safely, calling anything else is
not safe, but possible depending on the implementation. It is expected
the child should call exec-family functions almost immediately.

Even more complicated is using vfork safely from a multi-threaded
application. I have written up a very thorough example on this, but
have not posted it yet.

Cheers,
Carlos.