2025/06/02

Newest at the top

2025-06-02 03:56:06 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-06-02 03:55:54 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-06-02 03:55:41 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-06-02 03:48:18 +0200jmcantrell(~weechat@user/jmcantrell) jmcantrell
2025-06-02 03:48:04 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-06-02 03:47:42 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-06-02 03:45:43 +0200haritz(~hrtz@user/haritz) haritz
2025-06-02 03:45:43 +0200haritz(~hrtz@152.37.64.162) (Changing host)
2025-06-02 03:45:42 +0200haritz(~hrtz@152.37.64.162)
2025-06-02 03:45:11 +0200haritz(~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in)
2025-06-02 03:45:05 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2025-06-02 03:40:11 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-06-02 03:39:49 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-06-02 03:38:15 +0200_d0t(~{-d0t-}@user/-d0t-/x-7915216) {-d0t-}
2025-06-02 03:38:01 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-06-02 03:37:51 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-06-02 03:36:21 +0200mange(~mange@user/mange) mange
2025-06-02 03:35:07 +0200 <int-e> ...and break some foreign libraries that you might want to pass fds to as a bonus. ;-)
2025-06-02 03:32:51 +0200 <int-e> Anyway. This shouldn't distract from the point that read *can* block if the fd is not in non-blocking mode, and allowing blind reads simplifies some code..
2025-06-02 03:32:31 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-06-02 03:32:08 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-06-02 03:31:56 +0200 <int-e> (you still get partial reads but only on actual errors or EOF)
2025-06-02 03:30:49 +0200 <int-e> fread() does that loop for you, so if you took your semantics from there you'd be right.
2025-06-02 03:30:02 +0200 <EvanR> that's why you have to repeatedly write until everything goes through since it might return less than what you wanted to write
2025-06-02 03:29:49 +0200 <monochrom> Ah OK my bad.
2025-06-02 03:29:27 +0200 <monochrom> At this point I hope you don't react like my students. They are lazy and switch to read(fd, buf, 1) and be egregiously inefficient. GHC RTS cannot afford to do that, people would riot.
2025-06-02 03:29:23 +0200 <EvanR> yes it returns less than requested in blocking mode
2025-06-02 03:29:09 +0200_d0t(~{-d0t-}@user/-d0t-/x-7915216) (Ping timeout: 252 seconds)
2025-06-02 03:28:58 +0200 <int-e> You should get a partial read; it's supposed to block only when no data is available at all.
2025-06-02 03:27:35 +0200JuanDaugherty(~juan@user/JuanDaugherty) (Read error: Connection reset by peer)
2025-06-02 03:27:16 +0200 <monochrom> GHC uses green threads so all of RTS hangs.
2025-06-02 03:26:58 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-06-02 03:26:45 +0200 <monochrom> OK, even better example without racing. 2 bytes have arrived. But the thread called read(fd, buf, 10). Blocking mode hangs that read() waiting for 8 more bytes (or EOF or error).
2025-06-02 03:25:59 +0200 <EvanR> it *always* immediately returns an empty list
2025-06-02 03:25:52 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-06-02 03:25:32 +0200 <EvanR> now the behavior with lazy I/O is consistent
2025-06-02 03:25:25 +0200 <EvanR> k I messed up my original test by also pipe the fifo to stdin
2025-06-02 03:25:24 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-06-02 03:24:11 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-06-02 03:23:48 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-06-02 03:22:22 +0200 <EvanR> ?
2025-06-02 03:22:22 +0200 <monochrom> Alternatively, non-blocking mode relieves you from working so hard, while still be completely safe and correct.
2025-06-02 03:22:19 +0200 <EvanR> the RTS doesn't just make 1 thread at a time accessing the FD
2025-06-02 03:22:03 +0200xff0x(~xff0x@2405:6580:b080:900:9dbe:32d6:8014:9bea) (Ping timeout: 268 seconds)
2025-06-02 03:22:03 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-06-02 03:22:01 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds)
2025-06-02 03:21:47 +0200 <monochrom> I don't mean it is unsolvable. There is a way you can go out of your way to fool-proof that.
2025-06-02 03:21:22 +0200 <geekosaur> also that
2025-06-02 03:21:11 +0200 <geekosaur> yes, because it affects semantics of the FIFO, not just blocking-ness
2025-06-02 03:21:09 +0200 <monochrom> Suppose two threads race to read from the same FD. Suppose select detects that data has arrived. Should the RTS wake up just one of them? Or both of them? Either way is easily broken under blocking mode because you don't know how much each thread actually reads.