-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change TIdSocketListVCLPosix to use poll instead of select #473
Open
msccto
wants to merge
2
commits into
IndySockets:master
Choose a base branch
from
msccto:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nfds is defined as nfds_t, which is unsigned long int, and that's UInt64, not integer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically,
nfds_t
is simply defined as an "unsigned integer". Some platforms do useunsigned long
, but there are others that useunsigned int
instead.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just as i said t's defined in glibc as 'typedef unsigned long int nfds_t', but i do agree that there may be other definitions on different platforms, so i'd suggest using nativeuint here instead of integer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NativeUInt
probably would not be appropriate either, because of the platforms that useunsigned int
which doesn't change size between 32bit/64bit builds. There really needs to be separate platform-appropriatenfds_t
definitions.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're right, and this is actually the case with glibc where it is always unsigned long int both on 32 and 64 bit. still maybe unsigned long int itself differs on 32bit, can't really tell. but on ubuntu 22.04 which is always 64bit it's UInt64, i've checked that. but who knows, maybe it's only valid for gcc and not some other compiler, or is dependent on some 'compatibility' compiler options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as for the de-facto standard System V AMD64 calling convention implemented on most (if not all) *nixes it's safe to be defined as integer (at least when there are less then 2^32 fds allocated), because even when it is passed via EDI register, the higher bits of RDI are being zeroed rendering it a valid 64bit value. e.g. after these operations
the value of rdi would be 0 and not $ffffffff00000000
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but this is only valid for register-passed parameters (i.e. first 6 function parameters), if it's passed via stack (7+ parameter), or as a part of structure, or referenced by pointer it will cause trouble
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, yes. But that should not be a problem in THIS case since
poll()
has only 3 parameters and they are all simply types (1 pointer and 2 integers). The 1st parameter is a pointer to a struct, but that does not affect thenfds_t
parameter in question.