Support writing to block devices on MacOS#827
Support writing to block devices on MacOS#827aaronjeline wants to merge 1 commit intoocaml-multicore:mainfrom
Conversation
talex5
left a comment
There was a problem hiding this comment.
I assume this means that, if the resource isn't ready, then it will spin? That's not a problem for /dev/null but it might be for other things.
Possibly that's still better than the current behaviour, but needs a comment in the code that it should be improved if it turns out to be a problem.
Added a note about this. |
Does it block? I'd expect it to keep trying at 100% CPU instead (since we normally open things as non-blocking, it should get EAGAIN and try to wait again). I wonder if we should just use Any other mac users have thoughts about this? |
Do you mean just switch from I believe (2) is what libuv does |
|
Either would be fine I think. |
Block devices currently did not work on macOS, due to a bug that prevents poll(2) from working with block devices. This fixes that by creating a new thread that monitors block devices using select(2). The thread is created the first time a user computation attempts to read or write to a block devices. The implementation of the new select manager is in select.ml Additionally, the select manager also needed an eventfd system. The eventfd system from sched.ml was refactoring into a re-usable model that encapsulates some of the internal state in posix_eventfd.ml.
|
Latest commits spawns a new thread to handle block devices on macOS. Let me know if you want anything organized differently. Happy to adjust as you'd like. |
If we get
POLLNVAL, wake all of our readers/writers. MacOS will reportPOLLNVALfor any block device. Solves #757