Hi:
I get the FD immediately after accepting an incomig connection with
uv_fileno().
Then subsequently it is used as follows:
* IO_Task(): When the poll callback executes correctly, it is used with
Linux recv() to
read incoming network data in non-blocking mode. (All incoming data
and polling
is done in this thread/task.)
* Transmit_Task(): It is used with Linux send() to send data across the
network in non-blocking
mode. This thread/ task is driven by message reception outside Libuv
mechanisms.
That's it other than the final close() we discussed. I never observed
any problems unrelated
to Libuv connection acceptance and release, and starting and stoping
Libuv polling.
Best Regards,
Paul R.
On 05/09/2021 11:58 AM, Jameson Nash wrote:
Are you extracting a fd from a libuv object then calling close or
uv_poll on it? Either would cause problems, and shouldn't be done.
On Sun, May 9, 2021 at 2:53 PM Jameson Nash <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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 [email protected]
<mailto:[email protected]> <[email protected]
<mailto:[email protected]>> 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 [email protected]
<mailto:[email protected]>.
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:[email protected] <mailto:[email protected]>
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 [email protected]
<mailto:[email protected]>.
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/libuv/CADnnjUWfszx9K8FdGPwGD%3D_5C0s1QVrDkaJD2ML2%3DEygefFD_A%40mail.gmail.com
<https://groups.google.com/d/msgid/libuv/CADnnjUWfszx9K8FdGPwGD%3D_5C0s1QVrDkaJD2ML2%3DEygefFD_A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
Paul Romero
-----------
RCOM Communications Software
EMAIL: [email protected]
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/libuv/60983491.5060902%40rcom-software.com.
