| 12 Nov 2025 |
 Winter | and my memory+cpu being hammered | 20:03:29 |
| Winter | 😉 | 20:03:34 |
 ma27 | but, what are you referring to in the readme? afaiu it doesn't say something else (or rather, nothing on the default), no? | 20:06:53 |
| Winter | By default, nix-eval-jobs spawns as many worker processes as there are hardware threads in the system and limits the memory usage for each worker to 4GB.
| 20:07:22 |
| Winter | By default, nix-eval-jobs spawns as many worker processes as there are hardware threads in the system and limits the memory usage for each worker to 4GB.
| 20:07:30 |
| ma27 | ah right. | 20:08:51 |
| ma27 | yeah no you're right. | 20:09:17 |
| ma27 | feel free to file a cl :) | 20:09:21 |
| Winter | do we want to simply remove that note from the readme, or change nrWorkers to actually default to nproc? | 20:12:19 |
| ma27 | my personal preference would be to keep the behavior as-is and just fix the docs. | 20:15:45 |
| Winter | gotcha | 20:45:11 |
| Winter | learning that n-e-j doesn | 20:45:15 |
| Winter | ...'t die on sigpipe and groaning | 20:45:23 |
 raitobezarius | i think there's a bunch of CL improvements from aloisw on n-e-j | 21:56:52 |
| 13 Nov 2025 |
 aloisw | SIGPIPE is not in it though. Also it seems like the entirety of Lix just ignores it completely. I think the best way forward would not be to special-case it in nix-eval-jobs, but to treat as an interrupt like SIGTERM and SIGHUP. | 05:59:10 |
| Winter | i believe i only looked at nix but it appears that they’re not explicitly ignoring it at least, instead just saying to use the OS’ default signal handler for it? | 06:15:06 |
| Winter | and yeah, agreed | 06:15:10 |
