Clumsy interface of epoll
saurabhth
Please refer to the following definition of the structure epoll_data
typedef union epoll_data {
void *ptr;
int fd;
__uint32_t u32;
__uint64_t u64;
} epoll_data_t;
My doubt is related to the case when 'ptr' is assigned some allocated
memory and one wants to free it. Pls consider the following scenario:
1. TCP client connects to the server an the socket is added in the
epollset using EPOLL_CTL_ADD macro to epoll_ctl. Some information
related to this socket is allocated and associated with 'ptr' and
added:
struct epoll_event ev={0};
ev.events=EPOLLIN|EPOLLER;
ev.data.ptr = malloc(n); // This area is filled up with certain
info.
epoll_ctl(epfd,EPOLL_CTL_ADD,socket,&ev);
2. Please note that the same socket is used for reading/writing. The
TCP client writes to the socket and discovers that there is error on
socket and the socket needs to be closed.
My problem is that how do I free the memory that was associated with
the socket since there is no way I can get that memory other than
saving it in some form of list and indexing it by the socket. ?
I had assumed the calling epoll_ctl with EPOLL_CTL_DEL macro will help
retrieve the event structure whose pointer is provided in third
parameter:
epoll_ctl(epfd,EPOLL_CTL_DEL,socket,&ev); // I expect ev to return the
associated data that I can free but this does not happen
This in my opinion is wrong interface design. EPOLL_CTL_DEL must help
retrieve the associated data. Pls suggest some solutions - they must
be efficient too ?
David Schwartz
> 1. TCP client connects to the server an the socket is added in the
> epollset using EPOLL_CTL_ADD macro to epoll_ctl. Some information
> related to this socket is allocated and associated with 'ptr' and
> added:
>
> struct epoll_event ev={0};
> ev.events=EPOLLIN|EPOLLER;
> ev.data.ptr = malloc(n); // This area is filled up with certain
> info.
> epoll_ctl(epfd,EPOLL_CTL_ADD,socket,&ev);
> 2. Please note that the same socket is used for reading/writing. The
> TCP client writes to the socket and discovers that there is error on
> socket and the socket needs to be closed.
>
> My problem is that how do I free the memory that was associated with
> the socket since there is no way I can get that memory other than
> saving it in some form of list and indexing it by the socket. ?
You free it the same way you allocated it.
> I had assumed the calling epoll_ctl with EPOLL_CTL_DEL macro will help
> retrieve the event structure whose pointer is provided in third
> parameter:
>
> epoll_ctl(epfd,EPOLL_CTL_DEL,socket,&ev); // I expect ev to return the
> associated data that I can free but this does not happen
No, it does not.
> This in my opinion is wrong interface design. EPOLL_CTL_DEL must help
> retrieve the associated data. Pls suggest some solutions - they must
> be efficient too ?
You are arguing that something should be done in kernel space that can
more easily be done in user space. Do it in user space. If you need a
"file descriptor to pointer" mapping, create one.
DS
saurabhth
Hi David,
Thanks for your response.
From the manner that epoll_wait returns the event structure associated
with a file descriptor, I conclude that this thing is already
maintained in the kernel space. Therefore I find no reason why the
same thing be duplicated in the user space.
I fail to understand why this associated data of a fd cannot be
returned while deleting the fd from the epoll pollset.
Another design option could have been to take a free handler function
while adding fd to pollset. When the fd is being deleted from the
pollset, this handler function could be invoked to cleanup in the
kernel space.
Please let me know your views.
David Schwartz
> From the manner that epoll_wait returns the event structure associated
> with a file descriptor, I conclude that this thing is already
> maintained in the kernel space. Therefore I find no reason why the
> same thing be duplicated in the user space.
But it already is duplicated in user space. How did you decide which
descriptor to modify?
> I fail to understand why this associated data of a fd cannot be
> returned while deleting the fd from the epoll pollset.
Because there is no reason for kernel space to do something that can
be done just as easily in user space and also has to be done in user
space anyway.
> Another design option could have been to take a free handler function
> while adding fd to pollset. When the fd is being deleted from the
> pollset, this handler function could be invoked to cleanup in the
> kernel space.
>
> Please let me know your views.
You are completely missing the point.
*You* fed the descriptor to the kernel. From wherever you got the
descriptor, you could also have gotten the data.
When an event occurs, the kernel feeds the descriptor to you. You have
no opportunity to retrieve the associated data.
The assumption is that the application is rational and stores the
descriptor and the associated data in the same place. If you found the
descriptor, you could have found the associated data the same way.
There is no no reason for the kernel to waste its time doing that for
you.
However, if the kernel passes the descriptor to you, then there is no
way you could know the associated data, having not found the
descriptor.
The interface makes perfect sense. You are asking the kernel to do
work that serves no rational purpose.
DS
saurabhth
Hi David,
My apologies for yet not understanding your viewpoint. Allow me to
discuss with you the following scenario and help me point out any
deficiencies in my logic.
Scenario I - User space
========
Let us say that for every fd we have the following context:
typedef struct
{
int fd;
void (*fd_handler)();
}fdcontext_t;
For every socket fd that is created in the system, we add it to the
epoll pollset as follows:
void add_fd(int fd,void (*fp)())
{
struct epoll_event ev={0};
fdcontext_t *fdctx = malloc(sizeof(fdcontext_t));
fdctx->fd = fd;
fdctx->fd_handler=fp;
ev.events=EPOLLIN|EPOLLERR;
ev.data.ptr = fdctx;
epoll_ctl(epfd,EPOLL_CTL_ADD,fd,&ev);
}
epoll_wait will return the right context for a particular fd and hence
we would be able to call the right fd_handler to process messages/
error on that fd.
The problem arises in closing the fd. The problem here is that we are
unable to retrieve the fdcontext for the fd being deleted using
epoll_ctl and hence unable to free it.
Your quote
"The assumption is that the application is rational and stores the
descriptor and the associated data in the same place." means that this
program must create an association of an fd with its fdcontext
whenever we add the fd to epoll pollset.
The problem for a user space programmer is to find an effective search
mechanism to find the fdcontext associated with the fd when the fd is
being deleted and free the context.
Scenario II - Kernel space
===================
Please assume the same case that we are using add_fd function defined
above.
epoll_ctl with EPOLL_CTL_DEL returns the event structure associated
with the fd. The associated fd context is retrieved and freed.
This implementation can be duplicated from the behaviour of epoll_wait
as it invariably returns the associated data of an fd when the fd has
some event. In my mind, the implementation of epoll_wait is such that
it maintains such association and hence is capable of returning
associated data. Pls correct me if I am wrong.
Please let me know your views on each scenario.
Thanks.
David Schwartz
> > *You* fed the descriptor to the kernel. From wherever you got the
> > descriptor, you could also have gotten the data.
> > When an event occurs, the kernel feeds the descriptor to you. You have
> > no opportunity to retrieve the associated data.
> My apologies for yet not understanding your viewpoint. Allow me to
> discuss with you the following scenario and help me point out any
> deficiencies in my logic.
> Scenario I - User space
> ========
> Let us say that for every fd we have the following context:
> typedef struct
> {
> int fd;
> void (*fd_handler)();
>
> }fdcontext_t;
>
> For every socket fd that is created in the system, we add it to the
> epoll pollset as follows:
>
> void add_fd(int fd,void (*fp)())
> {
> struct epoll_event ev={0};
> fdcontext_t *fdctx = malloc(sizeof(fdcontext_t));
> fdctx->fd = fd;
> fdctx->fd_handler=fp;
>
> ev.events=EPOLLIN|EPOLLERR;
> ev.data.ptr = fdctx;
>
> epoll_ctl(epfd,EPOLL_CTL_ADD,fd,&ev);
>
> }
>
> epoll_wait will return the right context for a particular fd and hence
> we would be able to call the right fd_handler to process messages/
> error on that fd.
Right.
> The problem arises in closing the fd. The problem here is that we are
> unable to retrieve the fdcontext for the fd being deleted using
> epoll_ctl and hence unable to free it.
How did you know which 'fd' to close?
> Your quote
> "The assumption is that the application is rational and stores the
> descriptor and the associated data in the same place." means that this
> program must create an association of an fd with its fdcontext
> whenever we add the fd to epoll pollset.
How would you know which 'fd' to add to the pollset?
> The problem for a user space programmer is to find an effective search
> mechanism to find the fdcontext associated with the fd when the fd is
> being deleted and free the context.
That makes no sense. You must have already found the context --
otherwise how would you know *which* fd you were manipulating?
> Scenario II - Kernel space
> ===================
> Please assume the same case that we are using add_fd function defined
> above.
>
> epoll_ctl with EPOLL_CTL_DEL returns the event structure associated
> with the fd. The associated fd context is retrieved and freed.
>
> This implementation can be duplicated from the behaviour of epoll_wait
> as it invariably returns the associated data of an fd when the fd has
> some event. In my mind, the implementation of epoll_wait is such that
> it maintains such association and hence is capable of returning
> associated data. Pls correct me if I am wrong.
>
> Please let me know your views on each scenario.
However you decided which 'fd' to close or remove from the poll set,
you could also have retrieved the associated data. All you have to do
is store the associated data wherever you store the 'fd'. This is what
any rational program would do anyway.
This is in no way analogous to the case where an event occurs and the
kernel tells you the 'fd'.
DS
David Schwartz
You: "I want you to call Jack Johnson."
Kernel: "What's his phone number?"
Now, this makes sense. How is the kernel supposed to know what Jack
Johnson you want? You picked Jack Johnson, you should tell the kernel
his phone number.
You: "Is there anyone I need to call?"
Kernel: "Yes, Jack Johnson."
You: "What's his phone number?"
Now, this makes sense. The kernel told you to call Jack Johnson, so it
should supply the other information needed.
And this is exactly what 'epoll' does. Whoever supplies the 'fd' is
also expected to supply the associated data.
DS
Jasen Betts
> Hi all,
>
> Please refer to the following definition of the structure epoll_data
> typedef union epoll_data {
> void *ptr;
> int fd;
> __uint32_t u32;
> __uint64_t u64;
> } epoll_data_t;
this is a union so it can be used to store any one of the above.
> My doubt is related to the case when 'ptr' is assigned some allocated
> memory and one wants to free it. Pls consider the following scenario:
> 1. TCP client connects to the server an the socket is added in the
> epollset using EPOLL_CTL_ADD macro to epoll_ctl. Some information
> related to this socket is allocated and associated with 'ptr' and
> added:
>
> struct epoll_event ev={0};
> ev.events=EPOLLIN|EPOLLER;
> ev.data.ptr = malloc(n); // This area is filled up with certain
> info.
> epoll_ctl(epfd,EPOLL_CTL_ADD,socket,&ev);
>
> 2. Please note that the same socket is used for reading/writing. The
> TCP client writes to the socket and discovers that there is error on
> socket and the socket needs to be closed.
>
> My problem is that how do I free the memory that was associated with
> the socket since there is no way I can get that memory other than
> saving it in some form of list and indexing it by the socket. ?
that soulds like a good way to me, if you're only going to have a few
sockets open just use an array. the epoll_ev structure is small
(12-16 bytes) so having 10 or 1000 of them isn't likely to be a big deal.
> This in my opinion is wrong interface design. EPOLL_CTL_DEL must help
> retrieve the associated data. Pls suggest some solutions - they must
> be efficient too ?
you have access to the kernel source, fix it.
I suggest adding a EPOLL_CTL_GET opl that writes a copy of
the struct epoll_event associated with fd to the address given
in event. If you modify the behavior of EPOLL_CTL_DEL your
patch is likely to be rejected.
Rainer Weikusat
But epoll already maintains a 'dictionary' which maps fds to, say,
pointers, and being able to retrieve the 'value' for a given 'key'
even in absence of epoll_waitable events could certainly be useful.
According to the manpage, the original delete implementation expected
a valid pointer to an otherwise unused struct epoll_event. This was
later changed/ fixed but instead of ignoring the third argument, it
could as well be used to return the user data associated with the
to-be-deleted fd. How convenient or inconvenient that would be would
depend on the ratio of "don't care"/ "want to know" calls and an
interface to query the data without deleting the fd as a side effect
would IMO make more sense.
David Schwartz
> But epoll already maintains a 'dictionary' which maps fds to, say,
> pointers, and being able to retrieve the 'value' for a given 'key'
> even in absence of epoll_waitable events could certainly be useful.
In any reasonable scenario, user space maintains that same mapping as
well. For example, if you decide to shut down a connection from user
space.
> According to the manpage, the original delete implementation expected
> a valid pointer to an otherwise unused struct epoll_event. This was
> later changed/ fixed but instead of ignoring the third argument, it
> could as well be used to return the user data associated with the
> to-be-deleted fd. How convenient or inconvenient that would be would
> depend on the ratio of "don't care"/ "want to know" calls and an
> interface to query the data without deleting the fd as a side effect
> would IMO make more sense.
It makes no sense to do with a kernel call what can more easily be
done without one. Can you name any use case? How would the user space
program come to be interested in a particular descriptor in a way that
couldn't just as easily cause it know this data? Are you imagining
some case where user space just tries descriptors at random?
DS
Rainer Weikusat
> On May 26, 7:04�am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> But epoll already maintains a 'dictionary' which maps fds to, say,
>> pointers, and being able to retrieve the 'value' for a given 'key'
>> even in absence of epoll_waitable events could certainly be useful.
>
> In any reasonable scenario, user space maintains that same mapping as
> well. For example, if you decide to shut down a connection from user
> space.
Since there is no way to retrieve this data based on the fd but only
implicitly as part of an event notification, applications have to
treat the file descriptor as ancillary to whatever other 'control
information' might be required insofar 'control operations' on
arbitrary descriptors need to be supported. But because this is a
necessary consequence of the epoll-implementation, it cannot be the
reason for this particular implementation property at the same time.
>> According to the manpage, the original delete implementation expected
>> a valid pointer to an otherwise unused struct epoll_event. This was
>> later changed/ fixed but instead of ignoring the third argument, it
>> could as well be used to return the user data associated with the
>> to-be-deleted fd. How convenient or inconvenient that would be would
>> depend on the ratio of "don't care"/ "want to know" calls and an
>> interface to query the data without deleting the fd as a side effect
>> would IMO make more sense.
>
> It makes no sense to do with a kernel call what can more easily be
> done without one.
Ehh ... the data associated with the fd via epoll_ctl inside the
kernel cannot be determined at all. An appplication can, of course,
maintain an isomorphic dictionary on its own, but why have two, except
maybe as performance hack in certain cases?
> Can you name any use case?
What doesn't exist cannot be used. Conceivably, someone could name a
fictional use case, eg a self-contained 'close descriptor and free
ancillary data'-routine.
David Schwartz
> > It makes no sense to do with a kernel call what can more easily be
> > done without one.
> Ehh ... the data associated with the fd via epoll_ctl inside the
> kernel cannot be determined at all. An appplication can, of course,
> maintain an isomorphic dictionary on its own, but why have two, except
> maybe as performance hack in certain cases?
There is no need for the application to maintain an isomorphic
dictionary. Simply store the two things together in whatever data
structure you use.
> > Can you name any use case?
> What doesn't exist cannot be used. Conceivably, someone could name a
> fictional use case, eg a self-contained 'close descriptor and free
> ancillary data'-routine.
Right, but in order to call that routine, you'd have to know the
descriptor. How would you figure out which descriptor to close?
DS
Rainer Weikusat
Sorry, but you are simply evading the issue: Of course, an application
can be programmed such that it duplicates the functionality already
available in the kernel and there might even be good reasons for that
(eg, performance). Actually, applications can be written which
incorporate their own USB-drivers or filesystems. But for the
epoll-case, it has to be this way, because the interface doesn't
provide an event-independent lookup-routine. There may, in turn, be
good reasons for that, but these reasons cannot be that the
application has to be programmed in a certain way because there is no
other.
Eg, presently (for the one, epoll-based multiplexer I have written so
far), the way I do this is that I store a pointer to a 'control
structure' 'in a suitable way' for any subsystem which needs to
perform file descriptor control operation and store the file
descriptor in there, and every subroutine providing an implementation
of a file descriptor control operation takes such a pointer as an
argument, while - thankfully - the need to also map the descriptors,
as they are provided by the multiplexing-call itself, to control
structure pointer in reaction to event notifications has at least gone
away. But since people have been using poll/ select for quite some
time now, it is obvious that this, too, is a case where the kernel now
provides something which had to be provided by the application before.
I could theoretically as well store the descriptor and query the
control structure pointer whenever I need it outside the present event.
I see no reason why I would want to do so, since the system call is
likely going to take more time than traversing a RB-tree corresponding
with a realistically-sized descriptor set could ever possibly save,
but I still consider this (in absence of better arguments to the
contrary than 'performance') somewhat of a 'hole' in the interface.
David Schwartz
> Sorry, but you are simply evading the issue: Of course, an application
> can be programmed such that it duplicates the functionality already
> available in the kernel and there might even be good reasons for that
> (eg, performance). Actually, applications can be written which
> incorporate their own USB-drivers or filesystems. But for the
> epoll-case, it has to be this way, because the interface doesn't
> provide an event-independent lookup-routine. There may, in turn, be
> good reasons for that, but these reasons cannot be that the
> application has to be programmed in a certain way because there is no
> other.
I don't follow. That's exactly how you show that there is no use case.
> I could theoretically as well store the descriptor and query the
> control structure pointer whenever I need it outside the present event.
> I see no reason why I would want to do so, since the system call is
> likely going to take more time than traversing a RB-tree corresponding
> with a realistically-sized descriptor set could ever possibly save,
> but I still consider this (in absence of better arguments to the
> contrary than 'performance') somewhat of a 'hole' in the interface.
You don't need to traverse an RB-tree to find anything -- you already
found it. Since you have the descriptor, you have already found
whatever it is that holds the descriptor.
What is the use case you imagine where you have the descriptor but
don't have the thing that holds the descriptor? Where did the
descriptor come from -- outer space?
The logic of epoll is that any time you have the descriptor, you also
need the associated data. So the kernel should not give you the
descriptor and not give you the associated data. By following this
logic, you should not have the descriptor without having the
associated data.
Now, perhaps there is some case where you might have the descriptor
but not have the associated data, such that it might be useful to get
one from the other. But I can't imagine what that case might be. (And
every time I try to imagine one, I think of ten million reasons that
use case won't work.)
DS
Rainer Weikusat
> On May 27, 10:53�am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
>> Sorry, but you are simply evading the issue: Of course, an application
>> can be programmed such that it duplicates the functionality already
>> available in the kernel and there might even be good reasons for that
>> (eg, performance). Actually, applications can be written which
>> incorporate their own USB-drivers or filesystems. But for the
>> epoll-case, it has to be this way, because the interface doesn't
>> provide an event-independent lookup-routine. There may, in turn, be
>> good reasons for that, but these reasons cannot be that the
>> application has to be programmed in a certain way because there is no
>> other.
>
> I don't follow. That's exactly how you show that there is no use
> case.
TIMTOWTDI.
>> I could theoretically as well store the descriptor and query the
>> control structure pointer whenever I need it outside the present event.
>> I see no reason why I would want to do so, since the system call is
>> likely going to take more time than traversing a RB-tree corresponding
>> with a realistically-sized descriptor set could ever possibly save,
>> but I still consider this (in absence of better arguments to the
>> contrary than 'performance') somewhat of a 'hole' in the interface.
[...]
> What is the use case you imagine where you have the descriptor but
> don't have the thing that holds the descriptor? Where did the
> descriptor come from -- outer space?
,----
| I could theoretically as well store the descriptor and query the
| control structure pointer whenever I need it outside the present event.
`----
See, when I have the descriptor, I have (part of) the key the kernel uses to
lookup the associated pointer when the kernel needs it. So, could I
use this key to determine the pointer whenever I want, I wouldn't need
to store it anywhere else except inside the kernel data
structure. This would be a not particularly sensible way (IMO) to
reduce the 'storage requirements' of the application by one pointer
per participating descriptor.
David Schwartz
> > What is the use case you imagine where you have the descriptor but
> > don't have the thing that holds the descriptor? Where did the
> > descriptor come from -- outer space?
> ,----
> | I could theoretically as well store the descriptor and query the
> | control structure pointer whenever I need it outside the present event.
> `----
That use case fails, because you could more easily store the
associated data with the pointer. For a use case to succeed, the use
case must demonstrate a problem that's best solved with the proposed
new functionality rather than old functionality.
> See, when I have the descriptor, I have (part of) the key the kernel uses to
> lookup the associated pointer when the kernel needs it. So, could I
> use this key to determine the pointer whenever I want, I wouldn't need
> to store it anywhere else except inside the kernel data
> structure.
And that would be an advantage because ... ?
> This would be a not particularly sensible way (IMO) to
> reduce the 'storage requirements' of the application by one pointer
> per participating descriptor.
Congratulations, you have a use case that is "not particularly
sensible". If you can come up with a sensible use case, let me know.
DS
Rainer Weikusat
> On May 28, 5:23�am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> > What is the use case you imagine where you have the descriptor but
>> > don't have the thing that holds the descriptor? Where did the
>> > descriptor come from -- outer space?
>
>> ,----
>> | I could theoretically as well store the descriptor and query the
>> | control structure pointer whenever I need it outside the present event.
>> `----
>
> That use case fails, because you could more easily store the
> associated data with the pointer.
No, I cannot do so 'more easily' because not doing something cannot
possibly be more complicated than doing it. And this is somewhat
besides the point,
> For a use case to succeed, the use case must demonstrate a problem
> that's best solved with the proposed new functionality rather than
> old functionality.
because I am not trying to convince anyone of anything, but just to
explain why being able to query the userdata associated with a
descriptor in an epoll descriptor set *could* *be* *useful* in certain
circumstances. This would be even more true for the originally posted
idea, namely, that the otherwise-unused struct epoll_event * could be
used to return this information to the application when doing an
EPOLL_CTL_DEL.
Had I designed this interface, I would certainly have provided one or
both, because just because *I* *cannot* *presently* *imagine* *why*
*I* *would* *want* *to* *use* *this*, the possibility that someone
else could, and possibly even in a really intelligent way I am
presently too dense to think of myself, is certainly greater than
zero. Should I ever find one, I will simply change the kernel I am
planning to use accordingly. That's one of the beauties of 'open
source': It is not necessary to convince J. Random Bonehead[*] that
his code could be improved, one can just do this.
[*] While I had a couple of people in mind when writing this,
this is neither supposed to refer to anyone having participated in
this thread at any time and nor to any of the people who
designed and implemented epoll.
David Schwartz
> Had I designed this interface, I would certainly have provided one or
> both, because just because *I* *cannot* *presently* *imagine* *why*
> *I* *would* *want* *to* *use* *this*, the possibility that someone
> else could, and possibly even in a really intelligent way I am
> presently too dense to think of myself, is certainly greater than
> zero.
That's a justification for adding every imaginable feature.
http://en.wikipedia.org/wiki/Creeping_featurism
DS
Rainer Weikusat
Since I already wrote that "I am not trying to convince anyone of
anything" it isn't 'a justifcation' for anything. Something I further
like to add: I would never contemplate trying "to convince anyone of
anything". In the end, such a discussions almost always boils down to:
Random Person: But I need ...
Maintainer: I don't care [& go fuck yourself].
Random Sycophant: YOU INDESCRIBABLE OFFSPRING OF MILLIONS OF
GENERATIONS OF MUD-EATING SWAMP CREATURES !
YOU SOCIALLLY INCOMPETENT NERD !! YOU
PSYCHOTIC MONTROSITY WHOSE MERE EXISTENCES
ENDANGERS ALL MANKIND !!! [and so on]
Since the code is readily available and doesn't argue about the
relative sizes of particular body parts for the sake of doing so,
changing the code and being happy with the now solved problems is much
easier and much more sensible.
David Schwartz
> Since I already wrote that "I am not trying to convince anyone of
> anything" it isn't 'a justifcation' for anything. Something I further
> like to add: I would never contemplate trying "to convince anyone of
> anything". In the end, such a discussions almost always boils down to:
> Random Person: But I need ...
>
> Maintainer: I don't care [& go fuck yourself].
>
> Random Sycophant: YOU INDESCRIBABLE OFFSPRING OF MILLIONS OF
> GENERATIONS OF MUD-EATING SWAMP CREATURES !
> YOU SOCIALLLY INCOMPETENT NERD !! YOU
> PSYCHOTIC MONTROSITY WHOSE MERE EXISTENCES
> ENDANGERS ALL MANKIND !!! [and so on]
>
> Since the code is readily available and doesn't argue about the
> relative sizes of particular body parts for the sake of doing so,
> changing the code and being happy with the now solved problems is much
> easier and much more sensible.
That's a load of bull. More typically, the maintainer asks for a use
case, and the "Random Person" actually has no use case. Which, by the
way, appears to be what's happening here.
99 times out of 100, the "Random Person" thinks they want what they
originally asked for but it's usually because of something they don't
understand. The Maintainer is genuinely trying to help them understand
how to use the API. And they just keep insisting that the Maintainer
add the feature they think they need but actually don't.
DS
Rainer Weikusat
> On Jun 1, 7:47�am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> Since I already wrote that "I am not trying to convince anyone of
>> anything" it isn't 'a justifcation' for anything. Something I further
>> like to add: I would never contemplate trying "to convince anyone of
>> anything". In the end, such a discussions almost always boils down to:
>
>> � � � � Random Person: But I need ...
>>
>> � � � � Maintainer: I don't care [& go fuck yourself].
>>
>> � � � � Random Sycophant: YOU INDESCRIBABLE OFFSPRING OF MILLIONS OF
>> � � � � � � � � � � � � � GENERATIONS OF MUD-EATING SWAMP CREATURES !
>> � � � � � � � � � � � � � YOU SOCIALLLY INCOMPETENT NERD !! YOU
>> � � � � � � � � � � � � � PSYCHOTIC MONTROSITY WHOSE MERE EXISTENCES
>> � � � � � � � � � � � � � ENDANGERS ALL MANKIND !!! [and so on]
>>
>> Since the code is readily available and doesn't argue about the
>> relative sizes of particular body parts for the sake of doing so,
>> changing the code and being happy with the now solved problems is much
>> easier and much more sensible.
>
> That's a load of bull.
It isn't, because none of the wild assumptions you continue to make
all of the time happens to coincide anyhow with any reality. Eg, I
already had exactly this type of discussion, with 'part two' being
somewhat less impolite then described above, for daring to use a
while-loop instead of a for-loop in some code intended to fix a bug in
a particular Linux-driver (and switch for a multiway branch instead of
an if else if ...-cascade).
But this doesn't make this particular discussion any more useful.
David Schwartz
> > That's a load of bull.
> It isn't,
It's precisely what happened in this case. *Nobody* but you suggested
that the OP implement the feature himself. Nobody has yet presented a
use case.
> because none of the wild assumptions you continue to make
> all of the time happens to coincide anyhow with any reality.
That's certainly possible. Present a use case that holds up to
scrutiny, and I'll admit I was wrong. But there's zero evidence that
the OP has a use case.
> Eg, I
> already had exactly this type of discussion, with 'part two' being
> somewhat less impolite then described above, for daring to use a
> while-loop instead of a for-loop in some code intended to fix a bug in
> a particular Linux-driver (and switch for a multiway branch instead of
> an if else if ...-cascade).
In a discussion about which kind of loop to use, someone questioned
whether a proposed additional feature was useful and challenged the
person requesting it to write it?!
> But this doesn't make this particular discussion any more useful.
Yes, it is not useful to complain about a problem that is alleged at
least ten times more often than it happens. 99 times out of 100, when
someone says "if you want it, you implement it" it's because they
honestly think the reason you want it is erroneous. They're simply
exasperated at a lack of understanding the simple principle that it is
broken engineering to implement a feature that has no use case. (Of
course, if someone wants to break their own stuff, who's to care. But
to ask someone else to break their stuff for you -- no way.)
DS
Rainer Weikusat
> On Jun 1, 10:02�am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
>> > That's a load of bull.
>
>> It isn't,
>
> It's precisely what happened in this case. *Nobody* but you suggested
> that the OP implement the feature himself.
I didn't suggest anything as I have (as usually) already written a
couple of times. You were using a circular argument, which happened to
be the only reason for my original posting.
David Schwartz
> I didn't suggest anything as I have (as usually) already written a
> couple of times. You were using a circular argument, which happened to
> be the only reason for my original posting.
I don't know what you're talking about. I never used anything
resembling a circular argument.
I simply argued that there is no benefit to the operating system being
able to give you the additional information given the descriptor
because you can trivially find the additional information the same way
you found the descriptor, and that saves a trip to the kernel and
back. The additional information is useful when the kernel hands you
the descriptor because you don't have this opportunity and you've
already made a trip to the kernel.
How is that circular?
DS
Rainer Weikusat
> On Jun 2, 10:45�am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> I didn't suggest anything as I have (as usually) already written a
>> couple of times. You were using a circular argument, which happened to
>> be the only reason for my original posting.
>
> I don't know what you're talking about. I never used anything
> resembling a circular argument.
>
> I simply argued that there is no benefit to the operating system being
> able to give you the additional information given the descriptor
> because you can trivially find the additional information the same way
> you found the descriptor, and that saves a trip to the kernel and
> back.
[...]
> How is that circular?
Because the only reason the information can 'trivially' be found by
the application is THAT THERE IS NO OTHER OPTION.
David Schwartz
> > How is that circular?
> Because the only reason the information can 'trivially' be found by
> the application is THAT THERE IS NO OTHER OPTION.
No, that's not the reason. The reason is that the application found
the descriptor and could store the additional information with the
descriptor. (As explained three times already.)
DS
saurabhth
I have now fully understood what you are trying to say and have
designed my application in that way by storing the fd and its
associated data in one place.
Thanks for explanation and the patience that you showed.