Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm 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: Mon, 6 Dec 1999 23:48:15 -0500 To: Mumit Khan Cc: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: (patch) enable signals in dynamically loaded Cygwin DLL Message-ID: <19991206234815.A21564@cygnus.com> Mail-Followup-To: Mumit Khan , cygwin-developers AT sourceware DOT cygnus DOT com References: <199912070351 DOT VAA26863 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: <199912070351.VAA26863@mercury.xraylith.wisc.edu>; from khan@nanotech.wisc.edu on Mon, Dec 06, 1999 at 09:51:31PM -0600 On Mon, Dec 06, 1999 at 09:51:31PM -0600, Mumit Khan wrote: >Completely forgot about the synchronization used in makethread to avoid >stack corruption, and that's why enabling signals for dynamically loaded >Cygwin was crashing in newly created threads. > >This change removes the synchronization and uses dynamically allocated >memory to the thread stub routine, which frees the memory. The overhead >should be roughly the same, perhaps a tiny bit higher due to malloc's >internal MT synchronization. > >A gotcha for future users of makethread -- if you pass a thread parameter, >make sure it's not on the stack (which is the case currently, so it should >be safe). Note that this probably affects tty initialization too. It's not just signals that are affected, it's any thread that is started during DLL initialization. Since CYGWIN=tty implies the creation of several runtime threads, I assume that the problem is manifested there as well. cgf