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 
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to libuv+unsubscr...@googlegroups.com.
To post to this group, send email to libuv@googlegroups.com.
Visit this group at https://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

Reply via email to