Q1. There is a certain idiom used in libuv code (see this
-- namely using unprotected static variables to mark missing features (like
O_CLOEXEC). In multi-threaded environment these spots have a race
condition, which is in C++ workd is UB (undefined behavior) and compiler is
allowed to do interesting stuff that could break your app (in C++ compiler
is allowed to assume that your code has no race conditions). I am not so
sure about C, though -- hence the question: is this ok? shouldn't these
static variables be replaced with C equivalent of std::atomic<...>?
Another consideration is possibility of 'false negative'. For example, in
the link below if invalid mask somehow gets passed and open() returns
EINVAL -- it will activate the flag that will stay on until process exits.
Not sure if open() can return EINVAL on bad 'path'.
Q2. libuv tries to deal with EMFILE errors in accept() by closing "reserve
fd", accepting connection, closing it and reopening reserve fd again. It
isn't guaranteed to work in multithreaded env. What is the recommendation
for client's code to deal with EMFILE error that may bubble up?
As I see it I can:
- stop listening for a while and try uv_accept()'ing again. But then there
is no point in having (mandatory) "EMFILE-handling" trick -- I am dealing
with this myself anyway, no point in wasting one fd per eventloop
- tear down listening socket and try to restart it repeatedly (with some
delay) until it works -- again, no point in having that trick built in and
maybe it makes sense to make that trick optional? Unless there is a better
way for handling this situation...
Q3. EMFILE handling trick employs "reserve" loop->emfile_fd which is
populated by uv__open_cloexec("/", O_RDONLY) or
uv__open_cloexec("/dev/null", O_RDONLY). Isn't it a blocking operation? Why
not dup(STDOUT) instead?
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.