Boaz Segev <[email protected]> wrote:
> Running two (or more) event loops, each with it's own
> resources, is wasteful and promotes needless context switches.
>
> There is no reason to hijack a socket when the server can
> easily provide callbacks for IO related events using it's
> existing established event loop.
As Michael said, WS is a really bad fit for unicorn :)
> This alone should provide a performance boost. There are other
> considerations as well, but I think they all derive from this
> core principle of having the web server retain control over
> all network IO concerns.
For anybody else writing an epoll-based server with multiple
epoll-based event loops in different threads, the following is
good ordering; relatively cheap and scalable:
epoll_ctl(original_epfd, EPOLL_CTL_DEL, client_fd, NULL);
epoll_ctl(websocket_epfd, EPOLL_CTL_ADD, client_fd, &ev);
Change the order, and it's slower and less scalable:
/* in other words, don't do this in this order */
epoll_ctl(websocket_epfd, EPOLL_CTL_ADD, client_fd, &ev);
epoll_ctl(original_epfd, EPOLL_CTL_DEL, client_fd, NULL);
The former ensures a simple topology where the file behind
client_fd only exists in one eventpoll rbtree at a time. The
latter creates a complex topology which needs to do additional
locking and scanning to prevent infinite loops.
This is true since Linux 3.13, commit 67347fe4e632633
("epoll: do not take global 'epmutex' for simple topologies")
https://bogomips.org/mirrors/linux.git/commit?id=67347fe4e632633
> like hijacking, it's optional.
>
> Unicorn was design for very specific use cases, so I
> definitely understand if this might not be as interesting for
> you.
Yes, unicorn itself will never have a multi-client-aware event
loop. It is out-of-scope for its design, it seems WebSockets
usually have idle times which would cause any server with the
design of unicorn to fall over. unicorn cannot even handle
HTTP/1.1 persistent connections.
> However, I do think your experience as developers could help
> enrich us all. If you have any comments or anything to add
> regarding the proposed `websocket.upgrade` specification, your
> voice is welcome:
Sorry, not interested, and definitely not touching centralized
message boards :>
--
unsubscribe: [email protected]
archive: https://bogomips.org/unicorn-public/
