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 At Tue, 15 Dec 2020 13:12:16 -0500, James Platt wrote: > 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 > > -- > 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/01C7C30C-C75A-4498-A8FB-A5F7B1518 > 1E8%40biomantica.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 racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20201215113441.2a6%40sirmail.smtps.cs.utah.edu.
