Re: Two Console Communication (again)

"T.M. Sommers" wrote:
>
> Frank Kotler wrote:
> > "T.M. Sommers" wrote:
> >
> > [mmap MAP_ANONYMOUS | MAP_SHARED]
> >
> >>While it should work across a fork(), it will not work across an
> >>exec(). An exec()ed process gets a whole new memory space,
> >>unrelated to that of the parent process.
> >
> > Maybe I'm confused (well, I am, but how badly?)... I thought
> > sys_fork put us in a new address space, and sys_execve
> > "replaced" the caller's space...
>
> Yes, but ... . Most implementations of fork use copy-on-write
> with the child's memory, so that an actual copy is made only when
> the memory is written to. I would think that MAP_SHARED would
> tell the kernel not to make that copy even when memory is
> written. I can't think of any other use for MAP_SHARED | MAP_ANON.

Looks like it would be useful if you wanted to generate
-EINVAL for some reason...

> Try this:

Okay...

[snip]
> -> ./forkmap

mmap: Invalid argument :( Swapping to "MAP _PRIVATE works
(but we knew that). Looks like my kernel isn't happy with
MAP_SHARED | MAP_ANON ...or I'm doing something else
wrong... I suspect this is a "kernel version issue"...

> parent before: <not mapped> |abc| : <mapped> |abc|
> child before: <not mapped> |abc| : <mapped> |abc|
> child after: <not mapped> |XYZ| : <mapped> |XYZ|
> parent after: <not mapped> |abc| : <mapped> |XYZ|

As expected (?), the last "XYZ" is still "abc" with
MAP_PRIVATE. I think I'm beginning to get what "fork" does,
anyway. I'd been thinking we got a "new" "empty" space, but
we get a "new" "copy" of the parent's address space,
apparently. IOW, our strings are still in place... and our
code. This would have been obvious, if I'd thought it
through! If I understand "copy-on-write", it's actually the
*same* physical ram... until we write to it, when it's
copied(duh). This means that we've got "one way"
communication with our child (to pass a filename to open for
a "non-anon" shared area, e.g). But the child can't talk
back (hmmm... a child that doesn't talk back... the analogy
breaks down at this point :)

> > I still find the condition
> > after a sys_fork, where you're "two places at once", and eax
> > has a different value in each "place" to be a strange - and
> > slightly scary - situation.
>
> It is a bit odd. Take a look at setjmp/longjmp for something
> even odder.

I'd never have had any interest in setjump/longjump, but
somebody asked me about how to do it in asm (homework). I
don't recall if I ever got it working, but I agree it was
strange, alright.

> >>Have you tried using ftruncate(2) to expand the file after
> >>opening but before mmapping it?
> >> I don't know if that will work
> >>on Linux, but it does on FreeBSD.
> >
> > Yep! But the man page says it's "unspecified" whether the
> > file will be extended or left unchanged if it's shorter
> > (which it is).
>
> Expanding a file does seem to be a non-standard extension. Look
> at lseek(2) instead.

Okay, I'll give that a try. I can see that doing lseek first
might make ftruncate more reliable... maybe it'll do the job
by itself. I there a reason you don't like the "write a
byte" solution? Slower, I suppose, but we aren't doing it
that often...

It's beginning to look like I'm going to need a file - and
non-zero length, however I get it that way - to do this with
my kernel. I've been meaning to upgrade for a *long* time
now, but I'm kinda glad now I haven't done it - encountering
this may help me understand the "new features" better.

I still don't have confirmation that Randy's example will
run on any Linux machine. I'm fairly sure I could get it
working on my machine if the "open" and the "mmap" weren't
"wrapped" together. I haven't gotten into the nitty-gritty
code that does the job to see if a change there will fix it
- have to rebuild and reinstall the library to test it.
Maybe there's a "real bug" in there, maybe I just don't meet
"minimum system requirements". Lowering "minimum system
requirements" *might* be desirable even if it *is* a "kernel
bug"...

Anyway, thanks again for the assistance with this!

Best,
Frank
.

Relevant Pages

  • Re: fork() using multiprocessors
    ... Is it possible to use fork() to employ the ... // sum all elements ... like if all the process memory was shared. ... there's a memory protection trap into the kernel ...
    (comp.unix.programmer)
  • RH9 and memory leak ?
    ... (CRON) ... error (can't fork) ... Do I need to compile a new kernel? ...
    (RedHat)
  • Re: weird fork problem
    ... I am having a strange issue with a fork call. ... errno: Cannot allocate memory ... So, if you are running on Linux, you ran into a kernel structure out- ...
    (comp.unix.programmer)
  • Re: forking from a large active process in solaris
    ... No part of the system which performed a fork ... system which refuses the fork without knowing if the reserved memory ... and the reduced reliability is more than made up ... 'lazy swap allocation' implementation would need. ...
    (comp.unix.programmer)
  • Re: New Patch Fixes 43 Flaws In OS X, Many Serious
    ... Windows does not also do. ... You cannot handle all errors from fork(); ... swap space, forkwill not signal an error, but instead your Unix ... will start terminating processes to free memory. ...
    (comp.sys.mac.advocacy)