Threading question

[James Platt]

In Racket, does a given process have to be in a thread in order to give up time to other threads? In other words, putting code in a thread does not guarantee it will keep running if execution can move into other code that is not threaded?

Details:

I am working on documenting and writing examples for a NAT-Traversal package which is to be contributed as a Racket package. In order to keep a P2P connection alive, the NAT-Traversal (specifically STUN) process needs to keep sending pings back and forth between the peers. Otherwise, the firewalls involved will close the ports being used for the connection. To prevent this from happening, the NAT-Traversal code uses a lot of threading. However, I am still seeing connections drop. My example GUI chat client has a file transfer utility included but, if you take too much time in the open/save dialog selecting the file to send, it drops the connection and the file transfer fails. Do I need to put my GUI in a thread? Is that the issue? I'm asking here on the list, rather than just trying it, mainly because I want to be sure that I explain the situation correctly in my documentation.

James

[Matthew Flatt]

It sounds like you're running into a problem specifically with things
like the file dialog.

Everything in Racket runs in a thread. When your program starts, it
runs in the "main" thread. Normally, a Racket thread that can run will
run, no matter what other Racket threads are doing. When a
foreign-function call blocks its thread, however, then it blocks all
Racket threads --- at least, all threads in the same place.

Places offer one potential way out, because a blocking foreign call in
one thread does not necessarily block other places. In CS, the
foreign-function calls still have to be somewhat cooperative (by using
`#:blocking? #t` at the level of `_fun` or `_cprocedure`), otherwise
they can block even other places when a garbage collection is needed.
The file dialogs are not currently using `#:blocking? #t`, but I think
they could.

In the case of file dialogs, another option is `finder:common-get-file`
and `finder:common-put-file` from `framework`, which are Racket
implementations of those dialogs instead of calling the
platform-specific dialogs through foreign functions. Whether that's a
good option probably depends on your users.

Finally, Racket CS offers access to OS-level threads through
`ffi/unsafe/os-thread`. That's unlikely to be a good option, though,
because it can't cooperate with Racket's I/O layer.

Matthew

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/01C7C30C-C75A-4498-A8FB-A5F7B1518
> 1E8%40biomantica.com.

[James Platt]

I sent this reply to the list three days ago but it never made it back to me from the list so I am trying again. Apologies if you get it twice.

Thanks. The `finder:common-get-file` solution does the trick for my present purposes as just a demo of the NAT-Traversal code. In the long run I should learn more about places. Also, if there is enough interest in having a FOSS, decentralized Zoom equivalent in Racket, I will copy the GUI chat client code to its own project as a starting point and see who wants to help out. That is, once I finish with the NAT-Traversal package.

James