After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 659754 - Add API to GMappedFile that allows to pass FD, so that O_NOATIME can be used
Add API to GMappedFile that allows to pass FD, so that O_NOATIME can be used
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Philip Van Hoof
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-09-21 18:02 UTC by Philip Van Hoof
Modified: 2011-09-21 23:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch that implements this proposal (4.25 KB, patch)
2011-09-21 18:02 UTC, Philip Van Hoof
reviewed Details | Review
Improved patch based on comments by Colin Walter, Comment #2 (11.29 KB, patch)
2011-09-21 22:04 UTC, Philip Van Hoof
reviewed Details | Review

Description Philip Van Hoof 2011-09-21 18:02:43 UTC
Created attachment 197179 [details] [review]
Patch that implements this proposal

At Tracker we want to open files using O_NOATIME. With GMappedFile this is currently impossible.

For that reason I propose to add the API g_mapped_file_new_from_fd.

I have attached a patch that implements such an API.

I didn't let g_mapped_file_new reuse g_mapped_file_new_from_fd because otherwise the error messages couldn't use the display_filename.
Comment 1 Philip Van Hoof 2011-09-21 18:05:15 UTC
Example of a use-case where we had to stop using GMappedFile and start using mmap manually (unfortunately):

http://git.gnome.org/browse/tracker/commit/?h=o_noatime&id=cfb41b3abe99ff5e7782071840459646ef259c03
Comment 2 Colin Walters 2011-09-21 18:46:00 UTC
(In reply to comment #0)
> Created an attachment (id=197179) [details] [review]
> Patch that implements this proposal
> 
> At Tracker we want to open files using O_NOATIME. With GMappedFile this is
> currently impossible.

Good.  Please add this to the commit message; in general the commit message should have everything you wrote in this comment.  See https://live.gnome.org/GnomeLove/SubmittingPatches for how to write a good commit message.  The first line should look like:

GMappedFile: Add API to create from an existing file descriptor

> I didn't let g_mapped_file_new reuse g_mapped_file_new_from_fd because
> otherwise the error messages couldn't use the display_filename.

Hmm.  Couldn't you factor out a function which takes a display_filename or NULL for errors?  That's a lot of tricky code to basically copy.

Also, you need to update glib.symbols.  

And a test case would be good.
Comment 3 Philip Van Hoof 2011-09-21 22:04:04 UTC
Created attachment 197194 [details] [review]
Improved patch based on comments by Colin Walter, Comment #2
Comment 4 Colin Walters 2011-09-21 22:17:40 UTC
Review of attachment 197194 [details] [review]:

I like this much better!  A few minor comments below.

::: glib/gmappedfile.c
@@ +126,3 @@
                    g_file_error_from_errno (save_errno),
+                   _("Failed to get attributes of file '%s%s%s%s': fstat() failed: %s"),
+		   display_filename ? display_filename : "fd",

This would be a bit more work since you'd have to use two separate format strings, but you might give the number of the fd in the error, e.g. "fd 5".

Up to you, just pointing out it's possible.

::: glib/gmappedfile.h
@@ +38,3 @@
+GMappedFile *g_mapped_file_new_from_fd  (gint          fd,
+					 gboolean      writable,
+					 GError      **error) G_GNUC_MALLOC;

Should this be under #ifdef G_OS_UNIX ?  I don't think it's possible to use on Windows.  If you change this you'll also need the #ifdef in glib.symbols.
Comment 5 Philip Van Hoof 2011-09-21 22:31:46 UTC
I thought about this, but to be honest I don't really see the point in displaying the value of the file descriptor in the error message. Is there a good reason?

Afaik you can use this new API on Windows. The g_open part in the original code is/was also shared for both Windows and UNIX/traditional POSIX use.
Comment 6 Colin Walters 2011-09-21 22:44:24 UTC
(In reply to comment #5)
> I thought about this, but to be honest I don't really see the point in
> displaying the value of the file descriptor in the error message. Is there a
> good reason?

Probably in most situations by the time some developer sees the error message it'd be hard to track down which FD, so yeah, we can skip it.

> Afaik you can use this new API on Windows. The g_open part in the original code
> is/was also shared for both Windows and UNIX/traditional POSIX use.

Sure, filenames work fine on windows.  On win32 file descriptors are more special.  See this comment in giochannel.h:

 * On Win32, this can be used either for files opened with the MSVCRT
 * (the Microsoft run-time C library) _open() or _pipe, including file
 * descriptors 0, 1 and 2 (corresponding to stdin, stdout and stderr),
 * or for Winsock SOCKETs. 

Seems unlikely people get a fd from any of this and want to mmap it, but on the other hand it turns out g_io_channel_unix_new() is also on win32, so we can ship this there too.

So - good to commit.
Comment 7 Philip Van Hoof 2011-09-21 23:03:38 UTC
Alright done. Setting this bug as fixed.

http://git.gnome.org/browse/glib/commit/?id=ca154c399b879ad17804af5d9a81e607e049861e