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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20201215113441.2a6%40sirmail.smtps.cs.utah.edu.
