You're right: I had momentarily confused epoll with poll. You can just use the single file descriptor for an epoll object with things like `unsafe-file-descriptor->semaphore`, or you can use `unsafe-poller`.
I'll note that `unsafe-file-descriptor->semaphore` scales to a large number of file descriptors as long as you create a thread to block on each semaphore. Under the hood, creating and triggering fd-semaphores is implemented by incremental operations on an epoll object (or kqueue object, etc.), and each blocking thread will be descheduled until a semaphore post re-schedules it. But if you already have an epoll object and the code to handle it, then you don't need the semaphore-based machinery. Matthew At Tue, 4 Aug 2020 12:54:56 -0600, Robert D Kocisko wrote: > Thanks Matthew! That was my thought but given the number of fds in play > and the frequency of adding and removing interest in them (they are added > dynamically as needed) it seems like that option would be rather > inefficient. > > Is there by chance any 'magic back door' which would allow me to register > fds directly with Racket's underlying event loop so that I can bypass the > extra hops of the thread scheduler and the ffi boundaries? Or if not what > would need to be taken into consideration if I wanted to add such a back > door via modifying Racket's source? Are there any concerns with starving > other threads or other timing issues? > > Also I can't help but be intrigued by (unsafe-poller). I'm wondering what > benefits it might give (if any) in comparison with the approach you > suggested. > > Thanks, > Bob > > On Tue, Aug 4, 2020, 8:08 AM Matthew Flatt <[email protected]> wrote: > > > Fusing event loops is always tricky, but if you have the option of > > exposing individual file descriptors to Racket, then `ffi/unsafe/port` > > is probably the way to go. You can turn a file descriptor into an event > > using `unsafe-file-descriptor->semaphore` or `unsafe-fd->evt`, and then > > you can block on a set using `sync`, etc. > > > > Matthew > > > > At Mon, 3 Aug 2020 23:31:20 -0700 (PDT), Robert D Kocisko wrote: > > > I have an existing c++ app that is entirely event-loop driven with epoll > > > and I am trying to figure out how to integrate Racket in the same thread > > > and allow the existing code to work as-is. I have read the docs about > > the > > > C api and the FFI but so far a straightforward and clean option is not > > > apparent to me. The 'embedding' examples that I see appear rather > > opaque > > > to me and at best seem to be geared towards an external loop based on > > > select() rather than epoll(), so I'm assuming that the more > > straightforward > > > approach would be to add the existing event handlers onto Racket's event > > > system. To that end, it seems there should be a way to register the > > fd's > > > of interest with Racket and receive a callback when they are read-ready > > but > > > I can't see a way to do that. For example, how would I maintain a list > > of > > > fds to pass to (sync) if I went that route? Or if it's better to work > > it > > > the other way, how would I call (sync) from c code and apply the list of > > > fds to it? I vaguely can see a way towards it but it seems at best > > super > > > inefficient. Any thoughts or suggestions would be greatly appreciated! > > > > > > Thanks, > > > Bob Kocisko > > > > > > -- > > > 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 [email protected]. > > > To view this discussion on the web visit > > > > > > https://groups.google.com/d/msgid/racket-users/46fb3804-396c-4921-849f-71fe5a6f > > > ac7ao%40googlegroups.com. > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20200804133449.2e8%40sirmail.smtps.cs.utah.edu.
