[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[DotGNU]RE: [Gc] Using GC_CreateThread with CYGWIN builds

From: Thong (Tum) Nguyen
Subject: [DotGNU]RE: [Gc] Using GC_CreateThread with CYGWIN builds
Date: Fri, 28 May 2004 12:16:53 +1200

Here's an updated patch that doesn't require dynamic memory allocation.

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> On Behalf Of Thong (Tum) Nguyen
> Sent: Thursday, 27 May 2004 9:38 a.m.
> To: 'Boehm, Hans'; address@hidden; 'DotGnu-Develop'
> Subject: [Gc] Using GC_CreateThread with CYGWIN builds
> Hi,
> I'm one of the DOTGNU/pnet developers and I've been working on
> threading/gc
> support.  We use CreateThread when building on Windows regardless of
> whether
> we're using a CYGWIN or MINGW32 build.  Currently, libgc doesn't wrap
> CreateThread when using a CYGWIN.  I tried enabling the standard windows
> GC_CreateThread wrappers for CYGWIN but that appeared to be very unstable.
> The solution I eventually used (which is stable) is to write a
> GC_CreateThread implementation for CYGWIN builds that calls CYGWIN's
> pthread_create (mapping windows CreateThread semantics to pthread_create
> semantics).  CYGWIN's pthread_create will of course eventually call the
> real
> windows CreateThread API.  I think a possible reason why simply using the
> GC_CreateThread wrapper for normal builds crashes when using CYGWIN is
> because the CYGWIN runtime libraries expect threads to be created using
> pthread_create.
> In additional to the GC_CreateThread implementation for CYGWIN builds,
> I've
> had to change some GC_malloc_uncollectable/GC_free calls to malloc/free
> because calling the GC allocator while creating a new thread appears be a
> source of deadlocks between the GC and CRT.
> The patch is for v6.3alpha6 and is attached.
> All the best,
> ^Tum

Attachment: tum_cygwin_creatthread.patch
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]