[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
tum_cygwin_creatthread.patch
Description: Binary data