3 ms·

I'm working on my own userspace concurrency framework (early draft intro: http://team.s4y.us/ http://team.s4y.us/) and having fun with this stuff. > A lot of 3

I'm working on my own userspace concurrency framework (early draft intro: http://team.s4y.us/ http://team.s4y.us/) and having fun with this stuff. > A lot of 3rd party code doesn't work great with userspace threads. Agreed, especially since third-party code often calls standard library functions (`connect()`, `read()`, etc.) instead of the magic ones that are aware of your concurrency model. At OkCupid, we have our own database driver and RPC implementations that know how to use events for networking, and it sucks to have them in our codebase. > The final nail in the coffin for me was disk IO. Why not make it "somebody else's problem"? My thing uses libuv, which provides a common API and uses a thread pool or new async APIs under the hood. At OkC most filesystem access transparently goes through a separate process — it's just network access from the app's point of view. I guess what I'm trying to say is that if you can solve the problem once, you can make a nice abstraction on top of it and never think about it again (unlike dealing w/ third-party code and scheduling). Either way, I'd love your input on what I'm doing so far, you have way more experience.

mtanski 13y ago
Sid, Looking at your project, did you ever take a look at the Mordor C++ library (https://github.com/mozy/mordor https://github.com/mozy/mordor)? It looks like it predates your project by a quite a bit of time. It looks like you have a fun project on your hands and a lot of learning. My word of caution about having different scheduler for network / disk IO is that you end up creating latency. Depending on what you're doing this may or may not be an issue in your applications. If you're sensitive to that a large number of small size IO request will quickly do this. Then you're stuck trying to optimize this away (trading problems). If you're edge application does filesystem calls via some network abstraction you might be in a better place. If you're doing a network filesystem I recommend you check out Ceph. It both provides an in kernel Client (shameless plug I contributed code code there) which is nice because you can rely on the OS do cache things for you. It also provides a client library and the underlying RADOS object store library has non-blocking access to it. Check it out.

mtanski 13y ago

Sid, Looking at your project, did you ever take a look at the Mordor C++ library (https://github.com/mozy/mordor https://github.com/mozy/mordor)? It looks like it predates your project by a quite a bit of time. It looks like you have a fun project on your hands and a lot of learning. My word of caution about having different scheduler for network / disk IO is that you end up creating latency. Depending on what you're doing this may or may not be an issue in your applications. If you're sensitive to that a large number of small size IO request will quickly do this. Then you're stuck trying to optimize this away (trading problems). If you're edge application does filesystem calls via some network abstraction you might be in a better place. If you're doing a network filesystem I recommend you check out Ceph. It both provides an in kernel Client (shameless plug I contributed code code there) which is nice because you can rely on the OS do cache things for you. It also provides a client library and the underlying RADOS object store library has non-blocking access to it. Check it out.