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 Delivered-To: mailing list cygwin AT cygwin DOT com Date: Sat, 2 Feb 2002 00:40:57 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: A real fork() on NT Message-ID: <20020202054057.GA10185@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <006e01c1a96a$f60429a0$aace0544 AT CX535256D> <20020130131416 DOT D11608 AT cygbert DOT vinschen DOT de> <013a01c1ab96$839eefc0$0100a8c0 AT advent02> <000b01c1abaa$4e70f460$0100a8c0 AT gregmo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000b01c1abaa$4e70f460$0100a8c0@gregmo> User-Agent: Mutt/1.3.23.1i On Fri, Feb 01, 2002 at 09:27:21PM -0800, Greg Mosier wrote: >P.S. I would have dropped this awhile back with the exception of the cron >application. It appears to fork quite nicely under Win98, my OS. Now maybe >I'm wrong here, but seems to me if one app can fork that surely another >should be able to, no? Cygwin fork works just fine. It's slow but it should work as well as UNIX fork for a ported application. The only exception that I can think of is if you use dlopen to load a non-cygwin DLL. In that case there is a problem with relocation of the DLL after a fork. If you consider the number of applications that have been ported to cygwin, it would be pretty amazing if there was some basic problem with fork. cgf -- 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/