Re: [EXT] Re: Native threads and GC?

This is all running on 64-bit debian-testing. We call CHICKEN_initialize()
and CHICKEN_run() from the thread the chicken code is running in (not the
main thread).

We did not write this C code, and I suspect that disabling threads might not
be worth the effort required (not to mention that I'm not exactly a concurrency
expert). I will fiddle with the stack size and see if that helps.

Thank you for your response!

Durward

On 2/13/24 12:30, [email protected] wrote:
> APL external email warning: Verify sender [email protected] before clicking links or attachments
> 
>> We have a (32-bit, fwiw) C program that we are attempting to augment with a
>> CS function. The program runs in ~17 native threads, but our function only
>> runs in one of those threads. We call
>>
>>       CHICKEN_initialize(0, 0, 0, C_toplevel);
>>       CHICKEN_run(C_toplevel);
>>
>> after the thread is created, but then it goes off into libchicken and segfaults.
>> The last usefully-named function it calls is allocate_vector_2().
>>
>> Is there a useful way to debug what's going on? The threads exchange messages, though
>> I don't believe any of them should be in the purview of CS's GC. Am I missing something
>> obvious?
> 
> Is the Chicken code started in the main thread? Also, on what platform
> is this running? Threads other than the main thread often have a smaller
> default stack (depending on the OS used), so the thread's stack may be
> exhausted as the C code generated from Scheme uses the stack as a first
> level heap and so needs a bit of space.
> 
> You can also try to run the code with a single native thread for testing
> to at least have a base that works and continue by enabling threads
> from there.
> 
> 
> cheers,
> felix
> 
> 

-- 
Durward McDonell
[email protected]
240-228-2690 (DC)
443-778-2690 (Balt.)