3 ms·
>I would expect an OS capable of expending its swap file to try doing it before failing my malloc call though. It takes A LOT of time to expand the swap file.
by mariusmg 4y ago
>I would expect an OS capable of expending its swap file to try doing it before failing my malloc call though.
It takes A LOT of time to expand the swap file. So failing malloc immeditately seems, to me, the right way to handle it.
Maybe adding an optional callback to malloc to be notified when further allocations are possible would be a better way to handle this.
- jraph 4y ago> It takes A LOT of time to expand the swap file. So failing malloc immediately seems, to me, the right way to handle it. Maybe it'd be possible to check if expanding the swap file is possible, return and then actually expand the swap file when convenient. (I like being an armchair kernel developer :-))
- bogwog 4y agoBut 99.99999% of the time, when a program calls malloc, it needs it to succeed. So if there is a callback or something to notify that a wait is required or whatever, then 99.99999% of programs are going to do it. That means the high cost of expanding the swap file will be incurred basically every single time...so why not make that the default? In the rare case where a program wants to handle a failed allocation differently, then they should use a native system call that provides a more detailed interface than standard malloc. It doesn't matter if it's not portable since this is really a Windows-only thing. Crashing is not good for anyone. A temporary freeze sucks, sure, but that's what you get for not having enough memory. ...plus, it's not like random freezing is a foreign concept to Windows users.