epoll_threadpool - GitLite

KO | EN

gitlite — search

#javascript #hacktoberfest #react #deep-learning #linux #docker #macos #nodejs #awesome #kubernetes #awesome-list #vue #openai #open-source

epoll_threadpool

(★ 180)

A small, clean, linux-only thread-pool implementation using epoll with support for sockets, scheduled callbacks and TCP connections.

파일 탐색기

최종 버전 다운로드 (.zip)

- barrier.h
- eventmanager.cc
- eventmanager.h
- eventmanager_test.cc
- future.h
- future_test.cc
- iobuffer.h
- iobuffer_test.cc
- Makefile
- notification.h
- tcp.cc
- tcp.h
- tcp_test.cc
.gitignore
LICENSE
README.md

# 설치 가이드

1. 코드 내려받기

git clone https://github.com/aarond10/epoll_threadpool

깃허브에서 프로젝트 코드 전체를 내 컴퓨터로 내려받습니다.

cd epoll_threadpool

방금 내려받은 프로젝트 폴더 안으로 이동합니다.

2. Make

보통 추천

사전 준비물

Git GitHub에서 프로젝트 코드를 내려받으려면 필요합니다.
Make Linux/macOS는 보통 기본 설치되어 있습니다. Windows는 별도 설치(예: MSYS2, WSL)가 필요합니다.

make long_test

생성된 빌드 설정을 바탕으로 실제 컴파일을 진행해 실행 파일을 만듭니다.

✅ 에러 없이 끝나면 성공입니다. 생성된 실행 파일을 직접 실행해보세요.

이 레포의 README에 적힌 실제 명령어를 그대로 가져왔습니다.

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

EventManager 
============

This is a simple epoll() based thread-pool implementation for linux designed
to be fast and very easy to use.

How do I use it?
----------------

Basic event queing is simple:

using std::tr1::bind;
    EventManager em;

// Start 10 worker threads
    em.start(10);

// Execute a function ASAP
    em.enqueue(bind(&MyFunction));

// Execute a function in 10 seconds time.
    em.enqueue(bind(&MyFunction), EventManager::currentTime() + 10.0);

// Stop the event manager's threads. This call is optional. It will be
    // done if required when the EventManager is destroyed.
    em.stop();

The library also supports file descriptors:

int socketFd = ...;

using std::tr1::bind;
    EventManager em;
    em.start(10);

em.watchFd(socketFd, EPOLLIN, bind(&onReadEvent));
    em.watchFd(socketFd, EPOLLOUT, bind(&onWriteEvent));
    em.watchFd(socketFd, EPOLLHUP, bind(&onDisconnectEvent));

// ... sleep or do something else ...

em.removeFd(socketFd, EPOLLIN);
    em.removeFd(socketFd, EPOLLOUT);
    em.removeFd(socketFd, EPOLLHUP);

em.stop();

All event handlers will be run on the first available EventManager worker 
thread. Blocking functions are strongly discouraged due to the risk of deadlock
related issues. Its perfectly OK for code running on a worker thread to update
the EventManager it is running on with the exception of the stop() function.
The stop() function can only be called from a non-worker thread. Ideally it
should be called from the thread that created the EventManager to begin with.

Can you make it easier?
-----------------------

If you insist. The following addititional classes are provided to allow higher
level coding:

- TcpSocket - A receive and send buffering TcpSocket proxy. Provides receive and disconnect callbacks.
  - TcpListenSocket - A listening socket that creates TcpSocket instances when someone connects. Provides an "onAccept" callback.
  - IOBuffer - A buffering I/O class that defers memory copying as long as possible to avoid redundant copy operations. This is designed to make dealing with received data significantly easier.
  - Notification - A simple pthread-based notification class for blocking until triggered. This should *not* be used on worker threads if possible but can be used to safely clean up from the main application thread.
  - Future - A proxy object representing a return value that may be set at some stage in the future. This allows for conventional (synchronous) and callback-driven (asynchronous) use cases with minimal fuss.
  - Barrier - Provides a synchronisation point. This object provides a callback that should be triggered exactly N times. On the Nth time, it calls a function and deletes itself. This functionality *may* be rolled into the Future class at some stage (by chaining Futures).

Examples of how to use these classes will eventually arrive here. Until then, there are a bunch of unit tests sitting in the src/ directory that can be used as examples.

Tests
-----

I haven't bothered with any complex build systems. GNU make and valgrind are all that's required to build and test the library. For the paranoid (like me), you can run repeated tests with valgrind memory testing via:

make long_test

I'm not aware of any bugs but I would certainly be happier with more thorough unit tests. These will also probably appear with time but if you find this library useful, I'd certainly appreciate payback in the form of additional unit test patches. :)

Dependencies
------------

The library depends on the following packages:

- A recent version of g++ (with std::tr1 support for function, bind, shared_from_this, ...).
  - pthread
  - [glog](http://code.google.com/p/google-glog/) - used for debug logging
  - [googletest](http://code.google.com/p/googletest/) - for unit tests