Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Mon, 3 Jun 2002 13:21:30 -0500 From: Michael Potter To: cygwin AT cygwin DOT com Subject: Re: numerous bugs i've found in cygwin while developing XEmacs Message-ID: <20020603132129.H269776@lidp.com> Reply-To: pottmi AT lidp DOT com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.19i Organization: Life Insurance Data Processing Incorporated Phone: +1 630 829 7015 > >[1] mmap[] and fork[]. The "pdump" [portable dumper] method of > > implementing undumping for XEmacs writes out all the data into > > a large file during building, and then reads it in when the > > program starts. the file looks like this: > >-rw-r--r-- 1 Ben Wing None 3280684 Jun 2 02:58 xemacs.dmp > > > >if mmap support exists, it's loaded using mmap[]. This fails > > miserably when a fork[] happens, as the child evidently doesn't > > get the mmap[]ed data visible in it and thus seg faults occur. > > This is obviously not supposed to be the way things work. It > can't be as simple as "mmap doesn't work across forks". It could be as simple as the example I submitted last night. That submission includes a sample program. June 02, 2002 20:32 cygwin 1.3.10 fork+sockets+shmat/mmap=recreate_mmaps_after_fork_failed The sample uses shmat, but if someone is willing to work on it, I would be happy to submit the example using mmap. -- Michael Potter LIDP Consulting Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/