Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com From: Chris Faylor Date: Sat, 4 Dec 1999 21:10:34 -0500 To: Mumit Khan Cc: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: (patch) winsup noncygwin mess cleanup Message-ID: <19991204211034.A9950@cygnus.com> Mail-Followup-To: Mumit Khan , cygwin-developers AT sourceware DOT cygnus DOT com References: <199912050203 DOT UAA01202 AT mercury DOT xraylith DOT wisc DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <199912050203.UAA01202@mercury.xraylith.wisc.edu>; from khan@nanotech.wisc.edu on Sat, Dec 04, 1999 at 08:03:07PM -0600 On Sat, Dec 04, 1999 at 08:03:07PM -0600, Mumit Khan wrote: >One thing will not work for noncygwin apps as currently implemented >-- signal handling -- since it depends on synchronizing with another >DLL, but that's not going to work due to serialization issues in >LoadLibrary. I can make it work, but since Chris is going to change >signal handling anyway ... Oops. I meant to comment on this as well. I've actually already changed signal handling in my sandbox and I ended up doing it in such a way that it doesn't necessarily have to break dynamic loading. At the very simplest, you could still call sigproc_init when dynamically loading. It just won't be deterministic when the process is ready to receive signals. But, then, this was the way cygwin B20.1 works anyway... cgf