Porting embedded app from BC to CS

[thomas_d...@alumni.brown.edu]

I have some fairly simple code setting up an embedded Racket BC instance in a C++ coroutine, allowing me to call `scheme_dynamic_require` a module using a custom #lang (supported by an embedded module) and extract a cpointer matching a certain type tag from the exported symbols.

It looks like it should be possible to port this over to even simpler Racket CS code since Racket CS handles suspending itself between calls instead of assuming a main-loop program structure; however I have a few questions here:

 - What are the preconditions and error-handling setup for calling `racket_dynamic_require` and/or other `racket_*` functions?

 - How does one obtain a path from a C string to pass to `racket_dynamic_require`? (i.e. what's the equivalent idiom to `scheme_make_path`?

 - There don't appear to be documented equivalents to SCHEME_CPTRP and SCHEME_CPTR_TYPE. What does `racket_cpointer_address` do if the argument is not a cpointer, and is there some way to check the type tag without triggering garbage collection?

- One of the hassles with Racket BC is that the garbage collection algorithm intetionally triggers segfaults and uses a signal handler to resolve them, marking it hard to use GDB on the larger embedded application. Does Racket CS have the same behavior, or is this not a problem anymore?

Thanks!

[thomas_d...@alumni.brown.edu]

Gently bumping this thread in the hopes it might get some new eyes.

[Matthew Flatt]

At Fri, 5 Nov 2021 08:58:06 -0700 (PDT), "thomas_d...@alumni.brown.edu" wrote:
> - What are the preconditions and error-handling setup for calling
> `racket_dynamic_require` and/or other `racket_*` functions?

There's not really anything you can do to catch exception C-side right
now. If you need to catch exceptions, that has to be done Racket-side,
possibly with a helper created via `racket_eval`.

> - How does one obtain a path from a C string to pass to
> `racket_dynamic_require`? (i.e. what's the equivalent idiom to
> `scheme_make_path`?

You can use `Sstring` to create a Scheme string from a C string or use
`Smake_bytevector` plus `memcpy` to create a Racket byte string. For
conversions like `bytes->path`, use `racket_primitive` to get the
Scheme/Racket function and call it.

> - There don't appear to be documented equivalents to SCHEME_CPTRP and
> SCHEME_CPTR_TYPE.
> What does `racket_cpointer_address` do if the argument is not a cpointer,
> and is there some way to check the type tag without triggering garbage
> collection?

You can get `cpointer?` using `racket_primitive`. To disable garbage
collection, I don't have a better idea than using `disable-interrupts`
and `enable-interrupts` (again, obtained via `racket_primitive`),
although that's limited in the sense that `disable-interrupts` could
itself allow a GC through before disabling interrupts, at least in
principle.

> - One of the hassles with Racket BC is that the garbage collection
> algorithm intetionally triggers segfaults and uses a signal handler to
> resolve them, marking it hard to use GDB on the larger embedded
> application. Does Racket CS have the same behavior, or is this not a
> problem anymore?

Racket CS does not do that --- so, that's something easier, for a
change.


Matthew

[thomas_d...@alumni.brown.edu]

Thanks! A couple follow-up questions inline.

On Monday, December 20, 2021 at 2:34:29 PM UTC-5 Matthew Flatt wrote:

There's not really anything you can do to catch exception C-side right
now. If you need to catch exceptions, that has to be done Racket-side,
possibly with a helper created via `racket_eval`.

So what happens from the perspective of embedding C code if an exception occurs in Racket code it calls?

You can get `cpointer?` using `racket_primitive`. To disable garbage
collection, I don't have a better idea than using `disable-interrupts`
and `enable-interrupts` (again, obtained via `racket_primitive`),
although that's limited in the sense that `disable-interrupts` could
itself allow a GC through before disabling interrupts, at least in
principle.

 

I can't seem to locate `disable-interrupts` or `enable-interrupts`  via searching the docs, but it sounds like if I needed to compose a sequence of several calls into Racket while keeping a consistent view of memory on the C side, I could do something like:

racket_apply(racket_primitive("disable-interrupts"),Snil);

// sequence of racket_ function calls

racket_apply(racket_primitive("enable-interrupts"),Snil);

Does that sound correct?

[Matthew Flatt]

At Mon, 20 Dec 2021 11:57:29 -0800 (PST), "thomas_d...@alumni.brown.edu" wrote:
> So what happens from the perspective of embedding C code if an exception
> occurs in Racket code it calls?

It's not defined. In certain cases, control will escape from the C
code, I think, but it depends on how the C code was reached.

> I can't seem to locate `disable-interrupts` or `enable-interrupts` via
> searching the docs, but it sounds like if I needed to compose a sequence of
> several calls into Racket while keeping a consistent view of memory on the
> C side, I could do something like:
>
> racket_apply(racket_primitive("disable-interrupts"),Snil);
> // sequence of racket_ function calls
> racket_apply(racket_primitive("enable-interrupts"),Snil);
>
> Does that sound correct?

Yes. Those are Chez Scheme functions, so you'd have to look in the Chez
Scheme documentation, which is not currently incorporated into the
Racket documentation.

Probably it would make sense to have more direct support for these in
the C API, and I've put that on my to-do list.