This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: _exit() missing WSACleanup() call?

On Tue, Aug 06, 2002 at 05:44:20AM +0200, Juergen Buchmueller wrote:
> It actually seems to be the mmap() implementation which is giving me troubles. 
> [...]
> Now the first mmap() region seems to work fine and how I expected -- just as 
> it works under *nix, too. The 'sibling' child processes can write to each 
> other's memory. However, as soon as any child writes to the second anon + 
> shared mmap() region, the Windows memory usage goes up by an amount which 
> (exactly!?) matches the size of that region -- BTW: this is something like 
> 600KB.
> [...]
> Is there a hidden hierarchy in CYGWIN's mmap() implementation? Or with other 
> words, is writing to an anon + shared mmap()ed region from a sibling process 
> that is not a direct descendant of the parent that created a memory map, but 
> rather a child of another process created by a uber-parent which already 
> exited, something that should work?

In theory, it should.  In theory.

Could you run `strace -f' and look if there's

> I must admit that I am confused by my own code right now and even more by the 
> code and comments. I'm not an experienced multi process + daemon 
> author either. For now I sticked up, because crashing OSes make me sick ;-)

Please, could you try to create a simple testcase which exhibits that
behaviour?  Oh and, could you please tell which OS you're using?

I'm really trying hard to get a mmap() implementation which is as U*X
like as possible.  A simple testcase could help a lot.

> [2] I guess you know the fork2() stuff. It is described at e.g. 

No, I didn't know that stuff.  Did you try to change your implementation
so that you use fork() and really wait() for the children?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                      
Red Hat, Inc.

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]