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 On Dec 15, 2020, at 1:34 PM, Matthew Flatt wrote: > 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/B88F3221-72A7-4D8F-A034-B448DA803752%40biomantica.com.
