I am using thrift client inside vibe.d application. Currently thrift uses standard blocking IO calls. So I use async thrift client inside vibed. Some other libraries (e.g. ddb postgres drive) have special build option for using vibe.d IO library (fiber friendly). I created request in Jira https://issues.apache.org/jira/browse/THRIFT-3459 for integration thrift with vibed async IO.

Jens Geyer (member of thrift team) wrote:
As long as we don't add any dependencies that are not optional, that's fine. If this is going to add a hard dependency to whatever library and this is by no means convertible into something that can be added optionally, I'm not so sure if we really want this. Speaking about Thrift in general, we try to keep it free from hard dependencies.
If this can be made optional in some way, either by just optionally adding it to the current D project, or (in the case where Thrift compiler support is needed) to bind this additional dependency to an compiler parameter (like thrift -gen d:add_support_for_XYZ) and some majority of users wants this, e.g. because XYZ is state of the art, that's a different thing.
Could you please elaborate somewhat more about why you think this is a good addition?
@other D users: Your opinion is also important here.

----------

What do you think about integration vibe.d with thrift? Is vibed important enough for this request?

You would need to create vibe-aware alternatives to TSSLSocket and TSocket. You would need a server that can assign requests to new fibers. That's about it.

You could easily make this its own library. No need to modify thrift.

On Wednesday, 2 December 2015 at 04:40:41 UTC, Chris Wright wrote:
> You would need to create vibe-aware alternatives to TSSLSocket and TSocket. You would need a server that can assign requests to new fibers. That's about it.
>
> You could easily make this its own library. No need to modify thrift.

Ok this looks as right solution. I was on wrong way.

Thanks