On Mon, Dec 10, 2007 at 06:32:08PM -, Dave Korn wrote:
On 07 December 2007 20:52, Andreas Schwab wrote:
Dave Korn [EMAIL PROTECTED] writes:
Perhaps we could work around this case by setting environ in the parent
before the vfork call and restoring it afterward, but we'd need kind
On Mon, Dec 10, 2007 at 11:18:57AM -0800, Joe Buck wrote:
While the standard's wording might need fixing, with every implementation
of vfork I know of, there are no threads. It's a mechanism for systems
that don't support fork (or that can only do fork in a horribly
inefficient way, say
Dave Korn [EMAIL PROTECTED] writes:
On 07 December 2007 20:52, Andreas Schwab wrote:
Dave Korn [EMAIL PROTECTED] writes:
Perhaps we could work around this case by setting environ in the parent
before the vfork call and restoring it afterward, but we'd need kind of
serialisation there,
Andreas Schwab wrote:
Typically in a multithreaded environment vfork is mapped to fork anyway.
...which is what I don't understand about this whole thread. It seems
Dave is seeing some strange behavior in Cygwin, but Cygwin's vfork =
fork, there is no difference. There used to be a vfork
On Mon, Dec 10, 2007 at 02:22:45PM -0500, Daniel Jacobowitz wrote:
On Mon, Dec 10, 2007 at 11:18:57AM -0800, Joe Buck wrote:
While the standard's wording might need fixing, with every implementation
of vfork I know of, there are no threads. It's a mechanism for systems
that don't support
Joe Buck [EMAIL PROTECTED] writes:
I don't think it's wise to waste time fixing theoretical bugs
exposed by close reading of the standard. Now, messing with environ
with vfork will mess up the parent process, and if that happens it's a
bug. But getting around it by using fork will harm
Daniel Jacobowitz [EMAIL PROTECTED] writes:
On Mon, Dec 10, 2007 at 11:18:57AM -0800, Joe Buck wrote:
While the standard's wording might need fixing, with every implementation
of vfork I know of, there are no threads. It's a mechanism for systems
that don't support fork (or that can only do
Joe Buck [EMAIL PROTECTED] writes:
While the standard's wording might need fixing, with every implementation
of vfork I know of, there are no threads. It's a mechanism for systems
that don't support fork (or that can only do fork in a horribly
inefficient way, say because there's no MMU, and
On Mon, Dec 10, 2007 at 11:35:15PM +0100, Andreas Schwab wrote:
Glibc will map vfork to fork in a multithreaded environment.
LinuxThreads used to. NPTL does not; this caused various trouble for
GDB at the time.
--
Daniel Jacobowitz
CodeSourcery
On 10 December 2007 20:01, Brian Dessent wrote:
Andreas Schwab wrote:
Typically in a multithreaded environment vfork is mapped to fork anyway.
...which is what I don't understand about this whole thread. It seems
Dave is seeing some strange behavior in Cygwin, but Cygwin's vfork =
fork,
Hey all,
This is what posix says about vfork:
http://www.opengroup.org/onlinepubs/95399/functions/vfork.html
The vfork() function shall be equivalent to fork(), except that the behavior
is undefined if the process created by vfork() either modifies any data other
than a variable of
On 12/7/07 1:09 PM, J.C. Pizarro wrote:
Do you permit me a question for you?
Are important the suggestions?
J.C.Pizarro
JC,
The problem that many of us have with your responses is that they are
almost always content-free. You do not seem to grasp the basic
principles of the issues
On 07 December 2007 18:09, J.C. Pizarro wrote:
You're wrong. My suggestions are not based from school and are not useless.
Now /you're/ wrong: your suggestions *are* useless. You suggested using
inter-process communications to try and resolve a potential data-access race
condition between
J.C. Pizarro writes:
You're wrong. My suggestions are not based from school and are not useless.
My suggestions are based from university, books, papers and internet, and
i did put those by a same reason, my freedom.
You have the freedom to make useless postings to this list, just as we
2007/12/7, Joe Buck [EMAIL PROTECTED] wrote:
On Fri, Dec 07, 2007 at 05:41:50PM -, Dave Korn wrote:
On 07 December 2007 17:24, J.C. Pizarro wrote:
You can do a critical section mainly between processes
Thanks for your well-meaning attempt to help, but you don't understand
what
On Fri, Dec 07, 2007 at 05:41:50PM -, Dave Korn wrote:
On 07 December 2007 17:24, J.C. Pizarro wrote:
You can do a critical section mainly between processes
Thanks for your well-meaning attempt to help, but you don't understand what
we're talking about, and sending a generic list
On 2007/12/7, Dave Korn [EMAIL PROTECTED] wrote:
On 07 December 2007 18:09, J.C. Pizarro wrote:
You're wrong. My suggestions are not based from school and are not useless.
Now /you're/ wrong: your suggestions *are* useless. You suggested using
inter-process communications to try and
On 07 December 2007 17:24, J.C. Pizarro wrote:
You can do a critical section mainly between processes
Thanks for your well-meaning attempt to help, but you don't understand what
we're talking about, and sending a generic list of synchronisation techniques
without regard to their relevance or
Dave Korn [EMAIL PROTECTED] writes:
On the other hand, the setting of environ is very dubious and is
likely to break on real systems. The code should be changed to call
execve instead. Unfortunately there is no standard execvpe function.
Fortunately gcc never uses the variant which sets
Dave Korn writes:
Perhaps we could work around this case by setting environ in the parent
before the vfork call and restoring it afterward, but we'd need kind of
serialisation there, and I don't know how to do a critical section using
pthreads/posix.
A simple solution would be to call fork()
Dave Korn [EMAIL PROTECTED] writes:
Perhaps we could work around this case by setting environ in the parent
before the vfork call and restoring it afterward, but we'd need kind of
serialisation there,
Do we? vfork should block the parent until the child calls execve or
exit.
Andreas.
--
Dave Korn [EMAIL PROTECTED] writes:
Note the several calls to dup2() and close(), which seem to me to be calls
[to] any other function, and the setting of environ, which seem to me to be
modification of any data other than a variable of type pid_t used to store
the return value from
On 07 December 2007 16:59, Ian Lance Taylor wrote:
Dave Korn [EMAIL PROTECTED] writes:
Note the several calls to dup2() and close(), which seem to me to be
calls [to] any other function, and the setting of environ, which seem to
me to be modification of any data other than a variable of
J.C. Pizarro [EMAIL PROTECTED] writes:
| But random suggestions based on something you read in school are useless
|
| You're wrong. My suggestions are not based from school and are not useless.
| My suggestions are based from university, books, papers and internet
What is the difference?
--
24 matches
Mail list logo
