Re: ev_io_modify usage?

2023-01-02 Thread Marc Lehmann
On Mon, Dec 26, 2022 at 09:42:52AM -0800, Michael Stein  wrote:
> I'm new to libev and I see now that to support the various backends it
> has to require the watcher be stopped for any modification (other than
> the callback address).

Well, issues can be very hairy, and people's expectations can be all over
the place (for example, even "thread safe" can mean many very different
things), and documenting this so it works always for everybody is a
challenging thing: One could mention all limitations everywhere (good for
prople only referencing the docs), or only in a central place (good
for maintainers and people reading the documentatioon as a tutorial). OR
something in between.

However, re-reeading some parts of the docs, it definitely could be clearer
what was meant by access, and maybe some guidelines are missing. We did go
through the docs and made sure functions clearly are documented as safe to
call on active watchers, and hopefully made it clear that, generally, no
function is safe to call on active/pending watchers, and what to do about
that.

It's probably not optimal, but future releases will make this clearer.

Greetings,

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev


Re: ev_io_modify usage?

2022-12-26 Thread Michael Stein
On Mon, Dec 26, 2022 at 01:11:22PM +0100, Marc Lehmann wrote:
> On Sun, Dec 25, 2022 at 09:09:26PM -0800, Michael Stein  
> wrote:
> > So I'm not sure when anyone would use ev_io_modify
> 
> The documentatioon explains it: it is faster with some backends (e.g.
> epoll) because the file description is assumed to change. When using
> ev_io_Set, libev assumes that the file description might have changed.
> 
> > When io_cb gets control it has nothing to send so it uses ev_io_modify
> > to turn off EV_WRITE:
> 
> Did you stop the watcher before calling ev_io_modify?

No, to my dismay I did not. From man ev:

 As long as your watcher is active (has been started but not stopped)
 you must not touch the values stored in it except when explicitly
 documented otherwise.

I'm new to libev and I see now that to support the various backends it
has to require the watcher be stopped for any modification (other than
the callback address).

I was thinking of the parameters to poll and how when not in poll the
struct pollfd values are free to be modified before the next poll call.

Also, in my mind, I wrongly considered that I wasn't touching the watcher,
I pictured the ev_io_modify call was changing things.

Thank you, it's all clear now.

PS: I wonder if there is any code out there using libev which is
doing what I was doing and not noticing the 100% CPU...



___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev


Re: ev_io_modify usage?

2022-12-26 Thread Marc Lehmann
On Sun, Dec 25, 2022 at 09:09:26PM -0800, Michael Stein  wrote:
> So I'm not sure when anyone would use ev_io_modify

The documentatioon explains it: it is faster with some backends (e.g.
epoll) because the file description is assumed to change. When using
ev_io_Set, libev assumes that the file description might have changed.

> When io_cb gets control it has nothing to send so it uses ev_io_modify
> to turn off EV_WRITE:

Did you stop the watcher before calling ev_io_modify?

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev


ev_io_modify usage?

2022-12-25 Thread Michael Stein
I'm confused by ev_io_modify as it does seem to allow changing the events
the io watcher gets called for, however the backend is still waking up
for the events I've removed and running 100% CPU since they don't
go away.

So I'm not sure when anyone would use ev_io_modify

This is Linux (debian 11 bullseye) libev4:amd64   1:4.33-1.

I have some code which is the minimal start of a TCP server.
It successfully uses an io watcher on event EV_READ to get control when
there is a pending connection so it can do the accept.

After the accept, the callback routine creates a new io watcher for this
new connection with callback routine io_cb for events EV_READ | EV_WRITE.

When io_cb gets control it has nothing to send so it uses ev_io_modify
to turn off EV_WRITE:

   ev_io_modify(w, w->events & ~EV_WRITE);

This works in that it doesn't get called anymore for EV_WRITE events,
however an strace shows the program is still issuing poll for both
and continually waking up for the POLLOUT events (100% CPU):

I'm sure I'm misunderstanding something here...

 below:
 fd 3 is server socket for listen,
 fd 4 is the TCP connection

20:45:37.959358 bind(3, {sa_family=AF_INET, sin_port=htons(9000), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
20:45:37.959409 write(2, "server_addr.sin_addr.s_addr "..., 37) = 37
20:45:37.959465 listen(3, 3)= 0
20:45:37.959715 write(2, "makesock complete, nap 0x55e8934"..., 43) = 43
20:45:37.959778 poll([{fd=3, events=POLLIN}], 1, 59743) = 1 ([{fd=3, 
revents=POLLIN}])
20:45:43.768122 write(2, "accept_cb fd 3 data 0x55e8934456"..., 35) = 35
20:45:43.768315 accept(3, {sa_family=AF_INET, sin_port=htons(41458), 
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
20:45:43.768535 write(2, "accept fd 4 client_addr_len orig"..., 43) = 43
20:45:43.768664 write(2, "client IP 127.0.0.1 port 41458\n", 31) = 31
20:45:43.768725 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN|POLLOUT}], 2, 
59743) = 1 ([{fd=4, revents=POLLOUT}])
20:45:43.768792 write(2, "io_cb: w 0x55e893445cd0 revents "..., 46) = 46
20:45:43.768868 write(2, "send_do: w 0x55e893445cd0 revent"..., 36) = 36
20:45:43.768954 write(2, "w->events 3 ~EV_WRITE fffd r"..., 40) = 40
20:45:43.769033 write(2, "send_do: removing EV_WRITE\n", 27) = 27
20:45:43.769083 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN|POLLOUT}], 2, 
59743) = 1 ([{fd=4, revents=POLLOUT}])
20:45:43.769130 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN|POLLOUT}], 2, 
59743) = 1 ([{fd=4, revents=POLLOUT}])
20:45:43.769170 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN|POLLOUT}], 2, 
59743) = 1 ([{fd=4, revents=POLLOUT}])
20:45:43.769207 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN|POLLOUT}], 2, 
59743) = 1 ([{fd=4, revents=POLLOUT}])
20:45:43.769241 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN|POLLOUT}], 2, 
59743) = 1 ([{fd=4, revents=POLLOUT}])


___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev