Conversation

Notices

1. Embed this notice
   :blobcatflower: (methyltheobromine@netzsphaere.xyz)'s status on Thursday, 20-Feb-2025 21:22:50 JST :blobcatflower:

   • twinspin
   @twinspin6 when copying large files, gtk based programs freeze
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Thursday, 20-Feb-2025 21:22:49 JST 翠星石

     in reply to

     • twinspin
     @lucy @twinspin6 Let me guess, Gtk4 and Gtk5?
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Thursday, 20-Feb-2025 21:26:31 JST 翠星石

     in reply to

     • 翠星石
     • twinspin
     @lucy @twinspin6 It appears that GNOME developers programmed the foot wrong again and made graphical operations require disk write operations(!), meaning when you have heavy disk I/O, such time sensitive operations get delayed.
     
     GtK2 and GtK3 stuff doesn't really face such kind of issue until you try to browse files.
     snacks likes this.
   • Embed this notice
     snacks (snacks@netzsphaere.xyz)'s status on Thursday, 20-Feb-2025 21:35:54 JST snacks

     in reply to

     • twinspin
     @lucy @twinspin6 they don't use non-blocking io? Wtf??
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Thursday, 20-Feb-2025 21:39:58 JST 翠星石

     in reply to

     • snacks
     @snacks I/O is unfortunately inherently blocking and "non-blocking I/O" is actually polling to check if bytes are available for reading before trying to quickly read (blocking) and move on, or otherwise keep going and try again later and the poll part can end up blocking too.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Thursday, 20-Feb-2025 21:48:29 JST 翠星石

     in reply to

     • snacks
     • LisPi
     @lispi314 @snacks Interrupts often love blocking and take too long to return on all hardware;
     perf: interrupt took too long (2633 > 2500), lowering kernel.perf_event_max_sample_rate to 75000
   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Thursday, 20-Feb-2025 21:48:30 JST LisPi

     in reply to

     • 翠星石
     • snacks
     @Suiseiseki @snacks Couldn't all sorts of other signals like interrupts (bypassing the need for polling) be involved depending on the specific hardware?
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Thursday, 20-Feb-2025 22:02:06 JST 翠星石

     in reply to

     • snacks
     • LisPi
     @lispi314 @snacks The problem is electrical signalling - there is no guarantee that electrical operations are going to complete in the wanted time, meaning even with hardware design, there will always be corner cases where some things block.
   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Thursday, 20-Feb-2025 22:02:07 JST LisPi

     in reply to

     • 翠星石
     • snacks
     @Suiseiseki @snacks Interesting. I wonder if it's how they're used that's the issue or just signaling them is itself being a problem.