Newest at the top
2025-06-02 03:56:06 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
2025-06-02 03:55:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-06-02 03:55:41 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
2025-06-02 03:48:18 +0200 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
2025-06-02 03:48:04 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
2025-06-02 03:47:42 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
2025-06-02 03:45:43 +0200 | haritz | (~hrtz@user/haritz) haritz |
2025-06-02 03:45:43 +0200 | haritz | (~hrtz@152.37.64.162) (Changing host) |
2025-06-02 03:45:42 +0200 | haritz | (~hrtz@152.37.64.162) |
2025-06-02 03:45:11 +0200 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
2025-06-02 03:45:05 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
2025-06-02 03:40:11 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
2025-06-02 03:39:49 +0200 | sabathan2 | (~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 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
2025-06-02 03:37:51 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-06-02 03:36:21 +0200 | mange | (~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 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
2025-06-02 03:32:08 +0200 | sabathan2 | (~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 +0200 | JuanDaugherty | (~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 +0200 | merijn | (~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 +0200 | sabathan2 | (~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 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
2025-06-02 03:24:11 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
2025-06-02 03:23:48 +0200 | sabathan2 | (~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 +0200 | xff0x | (~xff0x@2405:6580:b080:900:9dbe:32d6:8014:9bea) (Ping timeout: 268 seconds) |
2025-06-02 03:22:03 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-06-02 03:22:01 +0200 | ljdarj | (~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. |