Extract system-specifics from Socket #10706
Conversation
| # Clear the @volatile_fd before actually closing it in order to | ||
| # reduce the chance of reading an outdated fd value | ||
| _fd = @volatile_fd.swap(-1) |
There was a problem hiding this comment.
Hmm. After looking at evented_close, I'm wondering a bit if it would make sense to split that method in two, one part that removes all pending events that would happen before closing, and one that wake up the result, called after everything. As @closed isn't volatile it seems strange to wake up stuff (that can be run in other threads) before we actually is done. Setting @closed to false like that is definitely safe in the single threaded mode, but in multithreaded I wonder how far the assignment to @closed may be moved around by the compiler and CPU.
There was a problem hiding this comment.
Sounds legit, but I'd prefer to leave such restructuring for a follow-up, to keep the complexity of this simple yet extensive refactoring low.
|
I added two more commits extracting behaviour specific to IP and TCP sockets. There are still a couple of system-specifics left (in |
System-specific parts of
Socketare extracted toCrystal::System::Socket.This is just a refactor with almost no semantic changes.
The basic system API is already verified to be compatible with the upcoming win32 implementation.
There are still a couple of
LibC's left, mostly for simple socket option getter and setters. I expect most should work with the winsock API as well, so it may not be necessary to abstract them. In any case, at this point the most suitable abstraction is not clear, and would need to be determined later in the porting process.