The essence of the algorithm (c libevent everything worked):

  1. One loop is used to listen to the socket.
  2. Several threads start, they hibernate. Each thread attaches an event to Read.
  3. According to the assemblet, they all awaken, and who had ... the first one awakened, he captured the mutex, took the connection ...
  4. We remove blocking, threads fall asleep., And our thread works out ...
  5. A pool is taken and a file descriptor and the necessary buffers (in / in) and structures are put into it. id block with mutex.
  6. Next, we organize self-made noblocked reading, code like buffer_event

  7. After the data will be given, we release the pool and the thread goes to sleep. further n 3.

I have an error:

 Assertion failed: (("libev: ev_loop recursion during release detected", loop_done != EVBREAK_RECURSE)), function ev_run, file ev.c, line 2392.

github code Reading the INSTALL file - for most unix systems, it should compile without problems, libev should be installed, if not compiled, then edit the path in the Makefile.am and then everything from the first step ./autogen.sh

  • Strange algorithm. Why accept () not to do only in one thread, and from the rest to organize a pool. They hang on the semaphore queue, in which accept-thread puts a new socket and makes a post. Next thread, taking the socket from the queue works with it. And nonblock in such a scheme is not needed at all. A pool of thread handlers can be made dynamic with high-low watermarks if desired. - avp
  • Got sample code? The algorithm is taken from Stevenson "Development of Network Applications", it is also used with libevent in memcached, and everything worked in my clone. Everything is done in the image and likeness .... but with libev stubbornly does not want, or something I did not take into account. - akalend
  • There is a C program in Linux (quite large). If there is time, I will pull out the pieces in one file, as an example. I didn’t come across libevent, I read it now on the wiki, and here is this phrase: raises some doubts about its smoothness in all operating systems. In general, I am wary of algorithms tied to signal processing. - What is your OS? - avp
  • @akalend, sorry for the delay. Put the program with an example of processing in the thread pool. Sorry, quickly extracting the relevant (and remaining healthy) code from this test. Measuring the processing time of network connections in various ways (clients and server on the same machine) of the program, or from the developed server (which I mentioned) does not have enough time. Look, the part relating to your question is mainly 1164-1173 and 1212-1224 (well, the functions called from there). Successes. - avp
  • thanks, be sure to see Axis Linux Production & OsX Development can be developed entirely on Linux (epoll) - akalend

1 answer 1

I did the classic “who managed, he ate” scheme: just like you started a thread pool (hereinafter called workers), in each worker I started ev_loop, for accept I created as many ev_io watchmen, Kolbek did it alone. Blocked by using the mechanism ev_set_loop_release_cb (loop, void (*release)(EV_P) throw (), void (*acquire)(EV_P) throw ())

A mutex that locks in acquire() and is released in release() for each cycle is different. He kills before starting the cycle, and inside the cycle, when needed, is released and retracted when needed, with the help of your callbacks.

In general, the picture is this: for an asynchronous accept, the event flies to all workers, for whom accept worked first, the client socket descriptor returned to it, -1/EAGAIN returned to the -1/EAGAIN . Further, the descriptor is fully serviced by the loop on which it worked. The load distribution is fairly uniform.

If something is not clear - I will add.

C ++ 11 example: https://gitlab.com/snippets/8201

  • There is a small chance that the author of the question asked in 2012 will not see your answer. Nevertheless, the answer will certainly be useful to future readers. - VladD
  • one
    Yes, I paid attention to the date, but the libev tag has only one question, and without a final answer. So the goal "for future generations" was set. I'll add a little more code. - Monah Tuk
  • The author saw, thank you. Here I was just recently asked how to do multi-thread processing for libev, I promised to do sample code. - akalend