Hi Rush,
Porting to ASIO is a great idea - I think you'll find that using it
requires a bit of finagling, as TSocket was designed for blocking
interaction. ASIO has blocking reads on sockets, but things get a bit
more complicated when mixing blocking reads with timeouts
(read/write/connect). It's doable, but you might need to enqueue reads
to the io_service then wait on a condition.
I began a port, but haven't had time to finish it. If you post
something publicly I'd be happy to contribute.
David,
2/ The concurrency code was designed to be implementation-neutral, so
it should be possible to swap out pthreads without any changes to
existing
code. If you need to make changes to an existing concurrency class,
please
bring it up with this list as early as possible.
According to the original whitepaper, I understand when you guys first
wrote thrift there wasn't a suitable concurrency library. With newer
versions of boost, I'm pretty sure there's a direct mapping from every
one of your concurrency class features to Boost.Thread. Nowadays,
Boost.Thread is full-featured, cross-platform, and really, really
bullet-proof. Do you think it's still necessary to keep the concurrency
stuff around? This seems like a solved problem.
I understand the implementation-neutral argument, but I don't know of
any other thrift implementation besides posix threads. Do you Facebook
guys have one? The one argument for custom concurrency might be C10k
stuff, but for that we've got TNonBlockingServer (which will convert to
ASIO beautifully!), right?
Erik
