3 ms·

fdclean() is not strictly needed and it haven't even existed in earlier versions of the library. But it turns out that when handling 10,000 concurrent connecti

• adrianratnapala 10y ago
  I am not really objecting to the need to clean up the fd-bookeeping data, just the interface. And it's not much of an objection. I guess the intention behind libdill is that applications will do their I/O using some abstraction layer anyway -- and layer can be libdill aware enough to call fdclean(). If that is the design philosophy, then does that means there would be problems if someone used some big external libray that did lots of its own I/O inside a libdill coroutine?
  • rumcajz 10y ago
    Here's the use case that drives the design of fdclean: Imagine a third party library makes a callback to your code and hands you a file descriptor. You can use it temporarily, but you have no idea what will happen to it after you return from the callback function. Will it live on? Will it be closed? The only way to deal with that is to purge any cached info about the fd before returning and pretend that you never had anything to do with that file descriptor. void callback(int fd) { fdin(fd); recv(fd, buf, len, 0); fdclean(fd); }