[gnutls-devel] GnuTLS | gnutls_record_send_file() (non-NULL offset) moves file descriptor offset while sending without KTLS (#1580)
Read-only notification of GnuTLS library development activities
gnutls-devel at lists.gnutls.org
Tue Sep 17 19:50:09 CEST 2024
Brian Denton commented: https://gitlab.com/gnutls/gnutls/-/issues/1580#note_2115433664
>My understanding is that you pass a single fd to multiple gnutls_record_send_file in a multithreaded scenario.
Exactly!
>What's your expectation on (not) advancing the fd? What is it rooted in, does sendfile(2) have guarantees on such multithreaded usage?
This is covered in the man page for sendfile() (see "If offset is not NULL"), since you know it is in section 2 and are still skeptical I went above and beyond and made a test program that can confirm the syscall works with multithreading (I can post a link here later today).
What happens with gnutls is I was straceing my server to see if the async IO is working properly https://www.bernmern.ca/programs/linux/bernweb/ and noticed read() and lseek() syscalls originating from gnutls().
I expect gnutls_record_send_file() to work like sendfile(), and like the documentation implies:
>If offset is NULL then file offset is incremented by number of bytes send, otherwise file offset remains unchanged.
https://www.gnutls.org/reference/gnutls-gnutls.html#gnutls-record-send-file
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1580#note_2115433664
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20240917/1a0ef449/attachment.html>
More information about the Gnutls-devel
mailing list