On Thu, Jan 20, 2011 at 1:41 PM, Anton Vodonosov wrote:
> I worry about this code: [...]
> Can we run it in parallel with GC?
>
It is not 100% safe for other reasons, but memory allocation is protected by
locks from other events such as garbage collection and memory allocation by
other threads.
20.01.2011, 14:55, "Juan Jose Garcia-Ripoll"
:
> On Thu, Jan 20, 2011 at 12:31 PM, Anton Vodonosov
> wrote:
>> It's a good idea, thanks. I will only need to think about race conditions,
>> like if GC starts after the sigwait returns, but before we called
>> GC_register_my_thread. Or this code
On Thu, Jan 20, 2011 at 12:31 PM, Anton Vodonosov wrote:
>
> It's a good idea, thanks. I will only need to think about race conditions,
> like if GC starts after the sigwait returns, but before we called
> GC_register_my_thread. Or this code doesn't allocate any heap memory and
> should not be pro
Hello Juan Jose. It's enough to have a fix for the old libc only. It's a good idea, thanks. I will only need to think about race conditions, like if GC starts after the sigwait returns, but before we calledGC_register_my_thread. Or this code doesn't allocate any heap memory and should not be protec
I only have one suggestion, which is to temporarily deregister that thread
so that the garbage collector does not suspend it. Something like
/* Waiting may fail! */
int status;
GC_unregister_my_thread();
status = sigwait(&handled_set, &signo);
if (status ==
Hello.
I am building ECL for glibc-2.2.5. With that old glibc version
a deadlock occurs any time when garbage collection starts.
I found out the mechanics of how it happens.
Not sure if you want to fix it, because the libc version is old,
but maybe you can provide an advice how can I workaround
