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: http://www.opengroup.org/onlinepubs/007904975/functions/fork.html -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: question about _exit() function
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 [EMAIL PROTECTED] To: rmkml [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] 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: http://www.opengroup.org/onlinepubs/007904975/functions/fork.html -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: question about _exit() function
rmkml wrote: 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! I can see how you might read it this way, but that's not really correct. The purpose of _exit() instead of exit() is to avoid calling the atexit() handler, the per thread data cleanup handlers, and the cancellation routines. In the case of a vfork(), it's undefined as to whether you will be operating against resources currently allocated and appropriately reference counted to the child, or whether you are operating against that of the parent. In the case of fork(), you are guaranteed to operate in the context of the child. Which you should use is dependent on your application. The normal operation of a fork() in a threaded program is to duplicate only the calling thread. If you have registered atexit(), per thread data cleanup handlers, or cancellation routines (or, in some cases, signal handlers), then when you call exit(), these things will be invoked. Consider that the thread forking has perhaps the responsibility of cleaning up a shared memory segment created by a task. You do *not* want to do this cleanup (which happens on an interface that you are manually resource tracking) in the child process in this case, since it could rip the shared memory segment out from under other processes which are using it. Rather than calling _exit() to avoid this, you probably want to call exit()... however, you must deal with detaching your registered handlers and avoiding your manual cleanup process. The correct way to do this is to disable them in the child by utilizing the function pthread_atfork() to disentangle them at fork time. See: http://www.opengroup.org/onlinepubs/007904975/functions/pthread_atfork.html Is the child a real process or because of the thread context a part of the parent process, so a new thread. It is a real process; the only thread running in this real process is a copy of the thread that was running at the time of the fork(). This is the primary reason that vfork() cautions against its use in POSIX documentation, and why it only permits either an _exit() or an execve(), and why you should avoid vfork(). In this case a pthread_exit() may be a better solution. Is that point a view complety wrong ? You likely do not want to use pthread_exit() in this case, since you are the only thread in a process. If you were to use this with vfork(), the combination would likely cause a program malfunction. If you were to use it with fork(), the combination may or may not be a problem. In the second case, the reason for this is that there exists the possibility that when you create the new process, it will link with object files with statically declared instances whose .init routines create worker threads. For example, the Netscape LDAP library is not threads-safe, so at one point I wrote a wrapper library that queued requests to a single worker thread that was created at the time the library reference was instanced via a .init section. Calls into the library queued requests, which were then serialized to the Netscape library, and responses were sent back out. The result looked like an LDAP client library that could be reentered, but which would serialize work to the non-thread-reentrant library under the covers. So the reason pthread_exit() should not be used is that you may not be the only thread running, and if so, there will be no pthread_join() called to reap your thread, and the other threads will continue indefinitely: you can't depend on not creating threads as a side effect of using various libraries or shared objects. 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 ... Without more detail, this is hard to pinpoint, since I don't really know what you mean by freeze, and there appears to be a language barrier to a precise explanation. Most likely, this is an interaction between the user space scheduler and the vfork(). Realize that in the 4.x series of FreeBSD, the pthreads are implemented with a user space scheduler. This means that following a vfork(), since there is only one schedulable entity, the process, all threads are suspended until your _exit(0 or execve() call (assuming that these do the right thing in the vfork() case interacting with threads, and POSIX says that it's undefined if this will happen). If you want other threads in your main applicaion to run concurrently with the child, you *must* use fork() instead of vfork(). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
question about _exit() function
Hi, 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 ? Thanks in advance for the reply. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: question about _exit() function
and I use freebsd v4.8. On Thu, 27 Nov 2003, rmkml wrote: Date: Thu, 27 Nov 2003 20:20:04 +0100 (CET) From: rmkml [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: question about _exit() function Hi, 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 ? Thanks in advance for the reply. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
