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: Wed, 20 Mar 2002 11:52:47 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: OT: possible project/research project Message-ID: <20020320165247.GJ2762@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <013a01c1cff2$e515c910$0200a8c0 AT sknet01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013a01c1cff2$e515c910$0200a8c0@sknet01> User-Agent: Mutt/1.3.23.1i On Wed, Mar 20, 2002 at 09:37:42AM -0000, Stephano Mariani wrote: >I would certainly agree with you about that, but the fact remains, a >lot of code, that cygwin exists to ease the porting of, uses it. If >the work was done on fork itself, it would help speed-up a lot more >that just configure (or similar) scripts. That is making the oft-repeated assumption that there actually *is* something that could be done to fork. At this point, I'd even take ideas over patches. However I'd like informed ideas not "Say, I've heard that you can do copy-on-write on Windows -- just make fork use that." FWIW, /bin/sh uses vfork these days which, is basically just a spawn call with some fd table copying overhead. cgf -- Please do not send me personal email with cygwin questions. Use the resources at http://cygwin.com/ . -- 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/