question about _exit() function

rmkml rmkml at
Fri Nov 28 06:51:45 PST 2003

Thanks a lot for the answer. I will change vfork() with fork().

An another question: in the man page of vfork() it is mentionned that
the fork() function has to use _exit(0) too when something wrong with the
execve() happens!
but in a thread context of my program, the use of _exit() may not be
best practice.
Is the child a real process or because of the thread context a part of
the parent process, so a new thread.
In this case a pthread_exit() may be a better solution.
Is that point a view complety wrong ?

Currently, is some indeterminate case, a part of my program freeze just
after the vfork().
So, I try to understand what may cause the calling thread of vfork() to
freeze ...

Thanks a lot!

On Fri, 28 Nov 2003, Terry Lambert wrote:

> Date: Fri, 28 Nov 2003 04:46:31 -0800
> From: Terry Lambert <tlambert2 at>
> To: rmkml <rmkml at>
> Cc: freebsd-hackers at
> Subject: Re: question about _exit() function
> rmkml wrote:
> > is the _exit() function safe for a thread ?
> > my program use vfork() and then execve in a thread context.
> > The documentation mentions that the process has to call _exit() in case
> > of failure.
> > But this _exit() is really safe for the parent thread ?
> The behaviour is undefined in the failure case, but only if you
> have stablishd a pthread_atfork() handler that does anything in
> the child.
> In general, the more correct approach is to use posix_spawn(), but
> FreeBSD doesn't support posix_spawn() (funny; this has come up now
> twice in within 60 messages of each other, while ther was a very
> long time when it was not pertinent at all...).
> POSIX also sriously discourages the use of vfork(), and recommends
> fork() instead, for threaded programs.
> Note that the fork() only *ever* creates a single thread, so it
> will only replicate the currently running thread and its address
> space, rather than all currently running threads in the parent.
> You said in another message that this is on 4.8.  I think that the
> behaviour will not be quite what you expect, in that case, and that
> it'll be better in -current, but might still not be what you expect
> there, either (depends on what you are expecting).  See also:
> -- Terry

More information about the freebsd-hackers mailing list