Hi:
u_accept() is in the main() task and uv_poll_stop() is int IO_Task().
However, I never observed
them executing concurrently with the same FD. What you wrote does make
sense and explains
a lot of things though. I guess that means uv_accept() somehow accesses
the same data
as uv_stop_poll() even though the poll handle is never passed to
uv_accept() !
Best Regards,
Paul R.
On 05/09/2021 11:53 AM, Jameson Nash wrote:
uv_poll_stop and uv_accept must happen on the same thread, so how are
they racing? Once uv_poll_stop is called, it should be safe to notify
another thread to call close, even if that then happens concurrently,
as the kernel should be thread-safe (though weird things may happen in
userspace if you close a fd that is concurrently in use on another
thread or event queue).
On Sun, May 9, 2021 at 1:24 PM Paul Romero <pa...@rcom-software.com
<mailto:pa...@rcom-software.com>> wrote:
Hi:
Using TSAN did turn up one very signifcant problem. The root cause
of the TCP socket descriptor corrpution
is that accept4() executes concurrently in the main() task, with
close() in the Protocol_Task().
As an interim measure I avoid the problem by simply not calling
close(). So far this has worked
seemlesly and Libuv appears to automatically free socket
descriptors. The Libuv documentation
about this is somewhat ambiguous. It indicates that after calling
uv_poll_stop() or uv_close(),
for a particular uv_poll_t poll handle, the socket descriptor is
returned to the user per the Libuv
contract. I am not sure what that means, and in particular, if it
means the socket descriptor is freed.
Can you clarify this ?
A tagential issue is whether Linux accept4() and close() are
thread safe. I believe they
are and the crucial data is protected in the kernel. Is it
possible Libuv is not handling the accept4()
return codes correctly ? The Linux accept4() man page details how
errors should be handled and is it
somewhat fussy. The Linux close() man page also details error
handling but it is straight forward.
Also, I haven't been able to make the program compiled with TSAN
dump core. Do you have
any suggestions ? Incidentally, I had to use clang rather than the
usual gcc to get
TSAN to work on my system.
Best Regards,
Paul R.
On 05/08/2021 08:51 AM, Jameson Nash wrote:
Are you still accessing libuv (sans explicitly thread-safe
functions such as uv_async_send) from multiple threads, as you
mentioned earlier? If so, I'd suggest fixing that first. In
conjunction, I recommend running TSan and making sure it runs
cleanly before checking for library or logic problems. Then, if
it is still a rare failure, I recommend debugging under `rr` as
you'll be able to run forward to the problem, then walk backwards
through the code to see what happened to your state and file
descriptors.
On Sat, May 8, 2021 at 11:27 AM pa...@rcom-software.com
<mailto:pa...@rcom-software.com> <pa...@rcom-software.com
<mailto:pa...@rcom-software.com>> wrote:
Hi:
Addition to my last message. When uv__nonblock() fails it is
indicative of a Linux FIONBIO ioctl() failure. What would cause
setting non-blocking mode to fail ?
Best Regards,
Paul R.
--
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
<mailto:libuv+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/libuv/CADnnjUW6KL3OQw5C54aNfKh95z1OpQiq2bgVtXya8z_BeqMS9w%40mail.gmail.com.
--
Paul Romero
-----------
RCOM Communications Software
EMAIL:pa...@rcom-software.com <mailto:pa...@rcom-software.com>
PHONE: (510)482-2769
--
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
<mailto:libuv+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/libuv/60981AE7.3000809%40rcom-software.com
<https://groups.google.com/d/msgid/libuv/60981AE7.3000809%40rcom-software.com?utm_medium=email&utm_source=footer>.
--
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
<mailto:libuv+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/libuv/CADnnjUVhyLDmxdxyyM5K1DL-%3DG6FK%3DY-OVE6ianUfpVC1AYeOQ%40mail.gmail.com
<https://groups.google.com/d/msgid/libuv/CADnnjUVhyLDmxdxyyM5K1DL-%3DG6FK%3DY-OVE6ianUfpVC1AYeOQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
Paul Romero
-----------
RCOM Communications Software
EMAIL: pa...@rcom-software.com
PHONE: (510)482-2769
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/libuv/609831B2.70004%40rcom-software.com.
