Georgy Kirichenko | 3 Feb 09:35 2016

libev error handling

Hi!

We use libev in our project (tarantool.org) and a problem with how libev 
handles its internal errors.
Periodically we need to create a new thread with libev pool and async. But in 
some cases process can haven't enough file descriptors to create pipe in 
evpipe_init (called by ev_async_start). In case of error libev will call 
ev_syscall and return to pipe creation. 
ev_syscall can abort process (this is unacceptable for us) or can callback if 
installed. But installed callback can't do nothing to break evpipe_init loop.

To fix this i create a patch, that allow early descriptors initialization at 
ev_loop_new, that can return NULL in case of errors. 
Attachment (ev.patch): text/x-patch, 3374 bytes
_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Ed Bukhman | 13 Jan 08:41 2016
Picon

strange goings on with an io watcher in windows

I'm hoping there is a good explanation for the behavior I'm seeing. I 
have a relatively simple client application which connects to a server 
and subscribes to a feed. The socket on the client is then associated 
with an io watcher running in the main event loop, so that messages are 
received and processed in a non-blocking way. The problem I'm 
experiencing is that it takes anywhere from 30 seconds to a minute for 
the watcher to be triggered for the first time, even though the server 
is emitting a message every couple of seconds. Once it has been 
triggered the first time, it then starts to respond to the messages as 
it is supposed to. Neither the size of the messages nor the frequency 
appears to have much influence on this delay.
I have confirmed with tcpdump that the server does in fact send every 
message. Also, if I take the recv() logic out of the callback function 
associated with the watcher and run it synchronously, everything works 
properly.
I'm at a loss to explain the observed behavior, and would appreciate 
either an explanation, or follow-up questions that would allow us to get 
to the cause of this.
Thank you
--Ed

_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Jérémy Lal | 11 Jan 21:49 2016
Gravatar

spelling in ev.pod: calender -> calendar

lintian stumbled upon that one.

Cheers,
Jérémy

_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Gar|k | 9 Jan 19:17 2016
Picon

ev_run() brakes - epoll_wait_nocancel

Hello, I do not know the English, but do not know where to turn.

it works, but in the processing of big data is break.

__epoll_wait_nocancel ()
__epoll_wait_nocancel + 10: cmp $ 0xfffffffffffff001,% rax
__epoll_wait_nocancel + 16: jae 0x7ffff74d2b2f <epoll_wait + 79>

All events and sockets are closed correctly. ev_pending_count() returns 0
I tried to call ev_invoke_pending() not help.

What could be the reason for such behavior?
_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Jason Madden | 8 Jan 16:42 2016
Gravatar

Compilation Error on SmartOS/Illumos/OpenIndiana

Hi all,

I'm a maintainer of the Python gevent library which wraps libev. Recently, we received a bug report [1] from
a user claiming compilation issues on SmartOS [2], which is a variant of OpenIndiana/Illumos [3], the
open versions of Solaris. 

Specifically, it turns out that Illumos now ships with an implementation of `inotify` [4], including the
header and init function. This is detected by the `configure` script and EV_USE_INOTIFY is defined.
However, the Illumos definition for `struct statfs` is incompatible with the Linux version, so
compilation fails.

This has been reported as a problem with other software, for example one of Facebook's projects at [5]. In
that project, they were able to make a code change to prefer the port backend and ignore the inotify
support. This seems better than hacking on `configure` as reported to gevent and to Facebook. It looks to
me like this should be possible in ev.c as well using something like the following patch (setting
EV_USE_INOTIFY to 0 if the Solaris port watchers are detected):

--- a/libev/ev.c
+++ b/libev/ev.c
 <at>  <at>  -127,6 +127,7  <at>  <at> 
 # endif

 # if HAVE_PORT_H && HAVE_PORT_CREATE
+#  define EV_USE_INOTIFY 0
 #  ifndef EV_USE_PORT
 #   define EV_USE_PORT EV_FEATURE_BACKENDS
 #  endif

I'm not able to test this and I haven't gotten feedback from our user. Has anyone run into this before and
solved it in a better way? If not, does this seem like a reasonable approach? Or should this particular
platform not be considered supported at this time?

Thanks,
Jason

[1] https://github.com/gevent/gevent/pull/711
[2] https://smartos.org
[3] http://wiki.illumos.org/display/illumos/illumos+Home
[4] https://github.com/joyent/illumos-joyent/blob/master/usr/src/uts/common/io/inotify.c
[5] https://github.com/facebook/watchman/issues/84
_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Kirill Timofeev | 29 Dec 21:20 2015
Picon

sharing udp socket between several processes

Hi folks,

I'm trying to have single udp socket opened by the master process and 
read data from it in the worker processes. Please find test source 
attached. I'm using following simple ruby script to generate test traffic:

#!/usr/bin/env ruby
require 'socket'

u = UDPSocket.new
u.connect("127.0.0.1", 1234)
10000.times do |i|
     u.send "this is line #{i}", 0
end

This works ok with single child:

$ ./a.out 1 1234 >log & ./gen-udp-traffic.rb && sleep 5 && killall a.out 
&& grep -c udp_read_cb: log
[1] 22560
[1]+  Terminated              ./a.out 1 1234 > log
10000

but I see that some incoming packets are lost with 2 childs:

$ ./a.out 2 1234 >log & ./gen-udp-traffic.rb && sleep 5 && killall a.out 
&& grep -c udp_read_cb: log
[1] 23387
[1]+  Terminated              ./a.out 2 1234 > log
8476

I run my tests on the ubuntu 14.04 x64. I use libev installed from the 
package:

ii  libev-dev 1:4.15-3                         amd64        static 
library, header files, and docs for libev

I compile my code using following command:

gcc 024-udp-test.c -lev

I tried to find any hints by googling, but unfortunately couldn't find 
anything relevant.

Please advise what should I do to avoid packet loss.

Thanks,
Kirill.
Attachment (024-udp-test.c): text/x-csrc, 3303 bytes
_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Marc Lehmann | 20 Dec 22:16 2015
Picon

libev-4.22 has just been released

I am pleased to announce libev 4.22!

Distribution: http://dist.schmorp.de/libev/libev-4.22.tar.gz
Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod?pathrev=rel-4_22
Changes: http://cvs.schmorp.de/libev/Changes?pathrev=rel-4_22

This release is mainly a bugfix release. Unless you are directly affected
by one of the fixes, there is no urgent need to upgrade.

The complete Changes are:

4.22 Sun Dec 20 22:11:50 CET 2015
        - when epoll detects unremovable fds in the fd set, rebuild
          only the epoll descriptor, not the signal pipe, to avoid
          SIGPIPE in ev_async_send. This doesn't solve it on fork,
          so document what needs to be done in ev_loop_fork
          (analyzed by Benjamin Mahler).
        - remove superfluous sys/timeb.h include on win32
          (analyzed by Jason Madden).
        - updated libecb.

--

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

_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Nick Zavaritsky | 15 Dec 18:22 2015
Picon

Several questions concerning libeio internals(+)

Hi!

I’ve implemented a support for using libeio from multiple threads for tarantool.org. Any interest in
this feature?

eio_init() initializes thread local state; a thread gets a private result queue + callbacks. There is the
single global request queue + a set of worker threads. Once a task is complete it moves into the
corresponding result queue. Embeding model is essentially the same: eio_poll fetches tasks from the
thread’s private result queue, registered callbacks are invoked when the result queue state changes.

It would be great if you answer several questions about libeio internals.

(1) What is the purpose of workers list? It is never used besides worker (un)registrations.

(2) Why does ALLOC macro lock pool->wrklock?

(3) Several pool attributes seem redundant. For instance, nready is essentially req_queue.size and
npending==res_queue.size. They aren’t redundant, are they?

Regards.
_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Chris Galas | 14 Dec 23:52 2015

ISO Example for reading/writing uart/rs-232

I’m looking for an example using ev_io with a uart/rs-232 (/dev/ttyS…).

 

Thanks

_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Chris Galas | 1 Dec 00:32 2015

ISO: A good example of associating custom data with a watcher (timer, etc.)

I'm looking for a good 'c' example of associating custom data with a watcher, say an ev_timer.

I subclass the ev_timer struct and then add my own data to the end. What will insure the 'base' come first in
memory versus my own data?

typedef struct ev_mytimer
{
  struct ev_timer base;
  void* myData;
} ev_mytimer;

Thanks!

_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Nick Zavaritsky | 23 Nov 14:20 2015
Picon

coro: Asm coro_transfer for arm7

Hi!

Please consider the patch implementing CORO_ASM backend for arm7 arch.

Regards.
Attachment (coro_transfer_arm7.patch): application/octet-stream, 4189 bytes
_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev

Gmane