If FFI for this particular library gets to be a headache, a backup
option might be to separate the Linux processes: make a small C program
that links in libhackrf, and provides some kind of channel (e.g., Unix
domain socket) for a separate Racket process to talk with it. Over the
channel, you can use s-expressions, Unix-ish line protocol, protobufs,
or something else. You'll have to check whether the communication
overhead of this is viable, but maybe it helps, in the balance, if
Racket is on its own core, and GC is not potentially interfering with a
time-sensitive thread of libhackrf.
FWIW, separate from the FFI difficulty, consider how much trust you have
in the perfection of all the additional memory-unsafe C code you'd be
pulling in via FFI, and how much you'd want to try to crash/corruption
of that (C, pthreads, separate VM, GC, large amounts of unfamiliar
complicated code...). That could be great educational experience,
especially in a hobby project, but probably not something you want to
risk in production if you don't have to.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/9a019c92-1db2-aa4d-9d3c-8735fbad2355%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.
