scheduler::add_thread caused problem, disabled(FIXED)- Cookie expiration doesn't work on Linux with time zone differs to UTC
Add signal handler to scheduler to handle Ctrl-C/Ctrl-D/...- No need, we can use
asio::use_future
to get a future and wait it with timeout, see echo_server example
- No need, we can use
- Make
concurrent_queue
fully work betweenfiber
andnot-a-fiber
c_q<fibers::mutex, fiber::c_v> can transfer data from outside to fiber, as long as there is no size limit(push won't block)c_q<std::mutex, std::c_v> can transfer data from a fiber to outside, as long as there is no size limit(push won't block)- Extra work is still needed to make both directions work with size_limit set
- Find a way to get stack track for uncaught exception in fiber
Find a way to properly implement timeout for async opsasio::use_future
can be waited with timeout
Future support(DONE)- Logging
- Async log (high throughput/low reliability)
- Sync log (low throughput/high reliability)
- Boost.Log integration (?)
- Log4CXX/Log4CPP/Log4CPlus (?)
- async/await support (?), this is little hard as creating coroutine inside a fiber may interfere with fiber scheduling, need to find a clean solution to support this
Make surefibio::condition_variable
andstd::condition_variable
can be used to communicate betweenfiber
andnot-a-fiber
Make sure(Only bare-notify works, as mutex only works inside of fibers, should not be big problem as fibio::condition_variable doesn't spuriously wake up waiters)not-a-fiber
can notifyfiber
viafibio::condition_variable
Make surefiber
can notifynot-a-fiber
viastd::condition_variable
- Make
future
to work betweenfiber
andnot-a-fiber
, for now it cannot as set_value/exception needs to lock mutex Shared mutex(DONE)- Windows support, will start as soon as I have access to a Windows machine with development tool installed :-(
- Fiberized main function, WinMain and ServiceMain, ANSI and Unicode version
- Windows handle stream(should work with some typedefs)
- Async file read/write(should work with some typedefs)
- Windows std stream guard(should work with minor efforts)
- Windows Service control
- HTTP
Cookie (DONE)- HTTP client
- Chunked response
- HTTP server framework
- Chunked resquest (File upload, etc.)
- Session store
- WebSocket
- RESTful service
HTTP request router for HTTP server (DONE)- Connection pool
- HTTPS support
- Template engine for HTTP server
- Stream with compression
- gzip
- Client can send compressed request
Client can receive compressed response (DONE)- Server can receive compressed request
- Server can send compressed response
- deflate
- gzip
- SMTP client to send mail
- Serialization
- JSON
- XML
- BSON
- Database driver
- Redis driver
- MongoDB driver(?)
- MySQL driver(?)
- Cassandra driver(?)
- RPC framework
- Thrift
- Protocol buffer based
- Fiber-local-allocator(?)
- fiber-local allocated containers(?)
- All script engines seem to have a GIL, not sure how will this impact performance?
- Lua/LuaJIT binding via LuaWrapper
- ChaiScript binding
- V8 binding(?)