| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Thanks for working on this, Tiran. It seems like it would be worthwhile to add a brief What's New entry for the addition of os.eventfd(). |
Sorry, something went wrong.
There was a problem hiding this comment.
I think the test class should be ran with Linux 2.27+ (to at least cover test_eventfd_initval) and then test_eventfd_semaphore (or any future tests that require use of the os.EFD_NONBLOCK flag) can require 2.30+. I'm not sure that it's entirely necessary or the number of devices it would actually be applicable to, but it seems like a better practice to have some amount of test coverage for 2.27 - 2.29 since the feature will be included in those versions.
Also, would it be worthwhile to add a test that makes use of select (maybe for poll and epoll as well, via mixin), which uses them to check if the file descriptor is ready for reading or writing? I suspect those will be typically used with os.eventfd(), so ensuring that behavior works as expected would make sense to me. I'm just not certain if it makes sense to include those in test_os, or if there might be a better location.
Sorry, something went wrong.
There was a problem hiding this comment.
It's actually 2.6.30, not 2.30. I'll fix that with the next commit. Linux Kernel 2.6.30 was released in 2009. It's highly unlikely that somebody is running a Kernel version between 2.6.27 and 2.6.30.
Sorry, something went wrong.
There was a problem hiding this comment.
It's actually 2.6.30, not 2.30. I'll fix that with the next commit.
Ah, good catch. I completely didn't notice the missing .6, despite recently reading over the man page for eventfd(). :-)
It's highly unlikely that somebody is running a Kernel version between 2.6.27 and 2.6.30.
Yeah, after looking over the dates for the releases, I'm now in agreement that it would be highly unlikely. If anything, I suspect most on the 2.6.x branch would be using 2.6.39 or 2.6.32.
(Based on https://upload.wikimedia.org/wikipedia/en/timeline/40658da696ee210d2be5f221ac12e43b.png.)
Sorry, something went wrong.
There was a problem hiding this comment.
I think this could be expanded upon a bit, specifically by:
E.g.
| Create an event file descriptor | |
| Create and return an "eventfd" file descriptor. It can be used as a lightweight | |
| event notifier. | |
| .. note:: | |
| Compared to a pipe that is exclusively used for event notification, | |
| `eventfd()` can be used as a more resource efficient alternative that | |
| only uses a single file descriptor and has far less overhead. |
While I agree with making the low-level OS functions that are thin wrappers to existing OS APIs fairly minimal in terms of documentation details (especially if they're already well documented), I think the existing one could provide a bit more information to the user that explains why they might want to use it.
For the full details one can view the man page, but IMO, we at least should summarize the general purpose. Otherwise, I suspect it will significantly deter discoverability of the feature.
Sorry, something went wrong.
|
I have updated the documentation, added a select() test case, and included eventfd_read + eventfd_write helper functions. They are just too useful to omit them. |
Sorry, something went wrong.
There was a problem hiding this comment.
This is nice, though I suspect eventfd_read does a system call even when uncontended?
Sorry, something went wrong.
There was a problem hiding this comment.
According to this man page, the initialization value is an unsigned int. In any case, I don't think it's useful to document the maximum value.
Sorry, something went wrong.
There was a problem hiding this comment.
I have updated the documentation. I think it's useful to document that the initial value is limited to UINT32_MAX while the maximum counter is UINT64_MAX - 1.
Sorry, something went wrong.
There was a problem hiding this comment.
What's the rationale for adding an availability markup for this data member but not the others?
Sorry, something went wrong.
There was a problem hiding this comment.
All other items have same availability as eventfd, semaphore came a bit later.
Sorry, something went wrong.
|
When you're done making the requested changes, leave the comment: I have made the requested changes; please review again. |
Sorry, something went wrong.
|
I have made the requested changes; please review again |
Sorry, something went wrong.
|
Thanks for making the requested changes! @pitrou: please review the changes made to this pull request. |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM (other than a minor suggested change for the whatsnew entry).
As mentioned in a previous review comment, I would prefer to have some mention in the docs of the specific use case for eventfd as a lightweight event notifier/waiter (essentially a brief summary of the "Notes" section from the man page) so that users are aware of its general functionality, even if they may not be already familiar with the system call. Unlike in the earlier years of Python, it's becoming increasingly common for developers to have started with Python before C (which has been my own experience). So, I think it's often quite helpful to at least have a summary of the purpose of the function, instead of assuming the reader is already familiar with it.
But IMO, it's fine to merge as is, that can potentially be considered as a future enhancement to the documentation. The core implementation of the wrapper, helpers, and the tests looks good to me.
(Note that I'm not particularly familiar with the details of implementing a CPython wrapper for a system call, I mainly used the existing members that work with FDs for comparison.)
Sorry, something went wrong.
There was a problem hiding this comment.
It seems all other modules / tests don't guard against select not being available. It looks like all platforms should support it (at least select.select).
Sorry, something went wrong.
|
@tiran This is more of a question than it is feedback, but is there a particular reason why we don't link to a specific man page for additional information here? I see that it's not done for other similar members that are effectively just wrappers for system calls, but it seems like it would be quite useful for readers in this case (particularly since our documentation of it is just a brief summary). This could very easily be done using the :manpage: inline sphinx role: :manpage:`eventfd(2)` |
Sorry, something went wrong.
|
I would suggest also to add a test using poll/epoll if available, but I don't feel strongly about it |
Sorry, something went wrong.
The ``eventfd_read`` and ``eventfd_write`` functions are convenient wrappers that perform proper read/write and conversion from/to uint64_t. Signed-off-by: Christian Heimes <christian@python.org>
Signed-off-by: Christian Heimes <christian@python.org>
- initval is a uint32_t - improve documentation - add whatsnew Signed-off-by: Christian Heimes <christian@python.org>
Signed-off-by: Christian Heimes <christian@python.org>
Co-authored-by: Kyle Stanley <aeros167@gmail.com>
|
@tiran: Please replace # with GH- in the commit message next time. Thanks! |
Sorry, something went wrong.
Co-authored-by: Kyle Stanley <aeros167@gmail.com>
| Back | FazBrowse Home | New Git URL |
Signed-off-by: Christian Heimes christian@python.org
https://bugs.python.org/issue41001