Fast event-loop networking for Go

Use sync.Once to make sure it would only call signalShutdow once when trying to shutdown evio cuz I found that it would call this function as many times as the number of loops and listeners, which is the redundant cost.

Code:

events.Opened = func(id int, info evio.Info) (out []byte, opts evio.Options, action evio.Action) {
    log.Printf("opened: %d: %v\n", id, info.RemoteAddr)
    return
  }

Output:

opened: 1: <nil>

Reduce at least one syscall.EPOLLOUT event in every connection, enhancing a bit of performance.

Benchmark between this branch and master:

Benchmark test in Amazon EC2:

c5.2xlarge (8 Virtual CPUs, 16.0 GiB Memory, 120 GiB SSD (EBS) Storage)
gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)

You would not want to use this framework if you need to handle long-running requests (milliseconds or more). For example, a web api that needs to connect to a mongo database, authenticate, and respond; just use the Go net/http package instead.

Why not? What will be the problem if I do so? Most request will be sub milliseconds but just one or two will be in the milliseconds... but I'm curious what will the problem be... can you elaborate?

I'm not really sure why but after a few hours of running with minimum connection ( around 100 ). CPU usage starts growing up to 100%. here is profile.

(pprof) top5 -cum
Showing nodes accounting for 9.86hrs, 79.77% of 12.36hrs total
Dropped 348 nodes (cum <= 0.06hrs)
Showing top 5 nodes out of 23
      flat  flat%   sum%        cum   cum%
         0     0%     0%   12.02hrs 97.25%  github.com/tidwall/evio.loopRun
   0.17hrs  1.40%  1.40%   12.02hrs 97.25%  github.com/tidwall/evio/internal.(*Poll).Wait
   0.08hrs  0.61%  2.01%   11.30hrs 91.41%  syscall.EpollWait
   9.57hrs 77.45% 79.46%   11.22hrs 90.80%  syscall.Syscall6
   0.04hrs  0.31% 79.77%    0.88hrs  7.13%  runtime.entersyscall

Graph:

Do you have any ideas about why it happens?

hi Josh Can you explain where the Reactor pattern is used in this project? I understand that the Reactor pattern and the Proactor pattern are implemented by the kernel, not the things that the application layer needs to worry about. Maybe I don't understand. I'm looking forward to your explanation.

#13 shows how to use Wake to write something, but comment of Wake says:

Not available for UDP connections.

Like i receive a tcp connection, how can i write to another udp conn?

The go goroutine scheduler already uses epoll/kqueue to decide when goroutines need to be scheduled.

Why is there a need to re-implement this, am I missing something?

Hey, thanks for the cool project. The name is conflicting with Go experimental UI lib, though. https://github.com/golang/exp/tree/master/shiny

I think in Go community name "shiny" is already strongly linked to this lib.

Opening this issue just to raise the concern as early as possible, because changing the name is easier at the early stage of project.

Hi: I found when set numLoops > 1, udp server with evio will be slower than numLoops = 1. Use profile, I found there is too much syscall in loopUDPRead(s, l, i, fd).
I add a debug code fmt.Println("-- loop udp read --", l.idx) before loopUDPRead, then send just one udp msg to it, there are numLoops's print in stdout. I change the LoadBalance to AtLeastConnections / RoundRobin, there is also more call to loopUDPRead when numLoops > 1.

See http://man7.org/linux/man-pages/man2/eventfd.2.html Bytes written into an eventfd object should have the same endianness as the host machine. Here I assume Poll.Trigger tends to incr by 1, not 1 << 56.

Since I consider evio the first/old school event loop libraries for Go I wonder what is the difference between all these newer ones like: https://github.com/panjf2000/gnet https://github.com/hslam/netpoll https://github.com/xtaci/gaio https://github.com/Allenxuxu/gev

It seems like they are all inspired by evio and then by one another so I am just curious to understand if there is some unique feature in these or if they are all one ant the same in principle and in performance?

In the end, I am quite confused to figure out which one to pick.

type loop struct {
	idx     int            // loop index in the server loops list
	poll    *internal.Poll // epoll or kqueue
	packet  []byte         // read packet buffer
	fdconns map[int]*conn  // loop connections fd -> conn
	count   int32          // connection count
}

why not use len(fdconns) instead of count?

https://github.com/tidwall/evio/blob/c72befaf8b4ff9419bcd8b150f582a358bebf33b/evio_unix.go#L421 should be c.out = append(c.out, out...), otherwise if calling multiple wake before loopWrite is called, only the last output is sent

The three questions are as follows: 1. When writing data to fd through the loopWrite function, you should check the number of successfully written bytes returned, because when writing some bytes successfully, if the write buffer of fd is full, err=syscall will also be returned .EAGAIN, which leads to repeated data writing next time. When the syscall.Write() function returns err, judge whether n is equal to -1, so as to slice the buffer of partially written data to avoid the next repetition Write.

2. When writing data to fd through the loopWrite function returns err=syscall.EAGAIN, call the Wake() function of conn to wake up the connection, wake up the Data() function of evio.Events in loopWake(), and return the data to be written to the connection, if the conn was previously .out has a buffer to be written, which will cause the previous buffer data in conn.out to be lost.

3. When writing data to fd through the loopWrite function returns err=syscall.EAGAIN, continue to call the Wake() function of conn to wake up the connection, wake up the Data() function of evio.Events in loopWake(), and return the large batch of data to be written by the connection, if The write buffer of fd has space to write. At this time, the fd is also triggered by a read event. When each epoll is triggered, only the loopWrite function will be processed, and err=syscall.EAGAIN will be returned when writing, which is the waiting time of fd. All data in the write buffer is not successfully written to fd, at this time the connection will be in a state of continuous writing, and each time epoll triggers the phenomenon that the connection read event is not processed, causing the fd read processing to starve .Note: This phenomenon should rarely happen, but I think it may happen if you do this

Fix typo in event.Tick example in README

-events.Tick = func() (delay time.Duration, action Action){
+events.Tick = func() (delay time.Duration, action evio.Action){
        log.Printf("tick")
        delay = time.Second
        return