Re: [racket-users] Threading question
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 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/B88F3221-72A7-4D8F-A034-B448DA803752%40biomantica.com.
Re: [racket-users] Threading question
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.
[racket-users] Threading question
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-A5F7B15181E8%40biomantica.com.
