On Tue, Feb 18, 2020 at 04:05:53PM +0100, Bo Lorentsen <[email protected]> wrote:
> >> that I can't read from, at all. recv returns -1 and EAGAIN, but it never
> >> gets any data.
> > You should not get readyness events from libev for sockets and then have
> > recv
> > return EAGAIN.
>
> No, and this is fortunately not what I experience :-) But I get a socket
> from accept, and I try to read from it ( a single time ) right away,
> just to see if it already contains data, and sometimes it does, at
> leased a bit of it, and sometime it just gives me EAGAIN++, as expected.
That is confusing - if you read from the socket _without_ getting a
readyness notification from libev, then of course you might get EAGAIN,
but that wouldn't have anything to do with libev, as it isn't involved,
right?
It would be more asurprising if libev told you you cna read and THEN you
got EAGAIN - this is possible, but shouldn't happen when you only read
after libev told you so.
> The problem is that sometimes I get a socket that never give me any data
> (or so it seems), so I ended up writing a small ev timer that "poked"
> this socket if no data was received for more then 10 sec (this is purely
> for benchmark purpose, so not for real life usage), and it did indeed
> still return EAGAIN++ as expected, and no data at all.
Yeah, that would either be a network problem, or what you think is the
socket actually isn't the socket (i.e. somehow the program confuses fd's
for example).
> and is blistering fast. There may be some kind of strange shadow effect,
> but to me at least it seems to boil down to me getting a socket from
> accept that is valid, but no data ever arrive here.
If that is the case,then it is because your kernel never received any data
for it - or your kernel is buggy, which is possible, but much less likely
than a bug somewhere else.
> You are absolutely right, this is very likely my code that have a bug,
> and this may be a cascading effect i don't understand. I just wrote
> here, to see if anyone have some experience with something like this, or
> maybe could spot the error in the test code. It is hard to find people
> in the C/C++ world that do things like this :-)
Well, I don't know if I am one of the poeple you want to reach, but of
course, I had buggy programs, too, and my first steps would usually be to
identify, with certainty, an fd that ahs the problem and see its kernel state
- if no data is there, then no data was received (or it eas read earler).
With TCP, iot is relatively easy to runa tcpdump and later identify the
connection, and then you cna see _exqactly_ what packets were exchanged.
That way you can find out with certainty whether the bednchmark tool sent
something, whether your receive socket received somethign,a nd thus rule
out your kernel, the benchmark tool, or your program.
If you don't know how to read tcp exchanges, learning it will go a long
way towards enlightenment (i.e. I think its worth learning in any case :)
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/mailman/listinfo/libev
