Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Seems like that functionality would better be included as separate madvise() advice than a new syscall, but probably a good addition either way.


The next email in that thread suggests using madvise() as well.


I'm a noob concerning all of this, but how would it be different to MADV_DONTFORK? Or why can't MADV_DONTFORK be used for the same task?


MADV_DONTFORK ends up working a bit different, when the forked process tries to read the page it ends up as a segmentation fault because the page wasn't carried over. It can be made to work but that ends up more difficult since you have to trap that signal and be able to prove you aren't going to catch a real one. Adding something like INHERITZERO would end up giving you a new blank page which would be much nicer to deal with in the userspace.


> MADV_DONTFORK ends up working a bit different, when the forked process tries to read the page it ends up as a segmentation fault because the page wasn't carried over. It can be made to work but that ends up more difficult since you have to trap that signal and be able to prove you aren't going to catch a real one.

Doubly difficult from within library code that needs to work in arbitrary programs, and thus cannot mess with signal handling.


There's a real need for per-memory-range segfault handlers.


I see.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: