"Ronald G. Minnich" wrote:
> On Wed, 12 Jan 2000, Luoqi Chen wrote:
>
> > It's almost a regular fork(), we lose all the advantages of a single
> > address space. A rfork(RFMEM) wrapper can achieve the same level of
> > usability without sacrificing the performance, and IMO is a preferred
> > solu
On Wed, 12 Jan 2000, Luoqi Chen wrote:
> It's almost a regular fork(), we lose all the advantages of a single
> address space. A rfork(RFMEM) wrapper can achieve the same level of
> usability without sacrificing the performance, and IMO is a preferred
> solution.
I don't see this at all. You get
> > Matthew Dillon <[EMAIL PROTECTED]> wrote:
> > > :BTW, concerning rfork(RFMEM). Could somebody explain me, why the
> > > :following simple program is coredumping:
> > > You cannot call rfork() with RFMEM directly from a C program. You
> > > have to use assembly (has anyone created a na
Ronald G. Minnich <[EMAIL PROTECTED]> wrote:
> On Wed, 12 Jan 2000, Alexander Litvin wrote:
> > Matthew Dillon <[EMAIL PROTECTED]> wrote:
> > > :BTW, concerning rfork(RFMEM). Could somebody explain me, why the
> > > :following simple program is coredumping:
> > > You cannot call rfork() with R
On Wed, 12 Jan 2000, Alexander Litvin wrote:
> Matthew Dillon <[EMAIL PROTECTED]> wrote:
> > :BTW, concerning rfork(RFMEM). Could somebody explain me, why the
> > :following simple program is coredumping:
> > You cannot call rfork() with RFMEM directly from a C program. You
> > have to u
On Wed, 12 Jan 2000 08:47:06 MST, Wes Peters wrote:
> Sheldon, do you want to tackle that one? You seem to be in a manpage mood
> these days.
If someone writes up plain text for the manual page, I'll be more than
happy to do mdoc mark-up and grammar clean-ups.
Ciao,
Sheldon.
To Unsubscribe
Matthew Dillon wrote:
>
> :>
> :> The reason is that rfork(RFMEM) does not give the new process a new
> :> stack, so both the old and new processes wind up on the same original
> :> stack and stomp all over each other.
> :
> :There is an implementation of clone() in the linuxthreads p
Matthew Dillon wrote:
>
> :>
> :> The reason is that rfork(RFMEM) does not give the new process a new
> :> stack, so both the old and new processes wind up on the same original
> :> stack and stomp all over each other.
> :
> :There is an implementation of clone() in the linuxthreads p
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> :BTW, concerning rfork(RFMEM). Could somebody explain me, why the
> :following simple program is coredumping:
> You cannot call rfork() with RFMEM directly from a C program. You
> have to use assembly (has anyone created a native clone() call
:>
:> The reason is that rfork(RFMEM) does not give the new process a new
:> stack, so both the old and new processes wind up on the same original
:> stack and stomp all over each other.
:
:There is an implementation of clone() in the linuxthreads port, written by
:Richard Seaman.
:
On Tue, Jan 11, 2000 at 09:56:58PM -0800, Matthew Dillon wrote:
>
> :> fork1() in the kernel]. rfork(RFMEM) means that the processes share all
> :> memory - current AND FUTURE. You could use minherit() before fork() to
> :> share current memory, but not future memory.
> :
> :BTW, concerning rfo
:> fork1() in the kernel]. rfork(RFMEM) means that the processes share all
:> memory - current AND FUTURE. You could use minherit() before fork() to
:> share current memory, but not future memory.
:
:BTW, concerning rfork(RFMEM). Could somebody explain me, why the
:following simple program is c
In article <1d5c01bf5c42$1409d990$[EMAIL PROTECTED]> you wrote:
> You've got that backwards - fork() and vfork() can easily be implemented in
> terms of rfork() [in fact, I believe all three are implemented in terms of
> fork1() in the kernel]. rfork(RFMEM) means that the processes share all
> m
> > Almost all of the flags it accepts seem like functionality that can easily
> > be implemented in userspace around fork() (and maybe vfork()).
>
> nope. This whole issue is about (let me check :-) ) 4.5 years old. I did
> the first rfork for freebsd ca. 9/1994, and I can tell you that you can
On Tue, 11 Jan 2000, Michael Bacarella wrote:
> I'm sorry I missed the discussion on rfork()... but I say this only
> because I want to understand.
>
> What were you thinking? rfork()? Why is it a system call?
>
> Almost all of the flags it accepts seem like functionality that can easily
> be im
Michael Bacarella <[EMAIL PROTECTED]> wrote:
> On Mon, 10 Jan 2000, Alfred Perlstein wrote:
> > I'm pretty sure RF_MEM doesn't work in 3.x with SMP, under UP it should
> > work fine
>
> I'm sorry I missed the discussion on rfork()... but I say this only
> because I want to understand.
>
> What wer
On Mon, 10 Jan 2000, Alfred Perlstein wrote:
> > :I've implemented a rough fix, which is to rfork() processes which I label
[snip]
> >
> > The linuxthreads port is at least four times faster and, since it uses
> > rfork(), will be I/O optimal. However, since only FreeBSD-4.x implements
17 matches
Mail list logo
