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

[Durward McDonell]

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, felix.winkelmann@bevuta.com wrote:
> APL external email warning: Verify sender felix.winkelmann@bevuta.com 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
durward.mcdonell@jhuapl.edu
240-228-2690 (DC)
443-778-2690 (Balt.)

smime.p7s
Description: S/MIME Cryptographic Signature