Yeah - unfortunately that’s why I said that I didn’t see how you could make this change without changing the generated code.
All the server does is accept() and pass off the accepted connections to the processor. Right now it passes off those connections in a threadpool because the generated processor is blocking. To make it non-blocking you’d have to rewrite the processor and the generated code. It’s practically rewriting the entire code-generator. This is also why I’ve been waiting for the async story to stabilize; I really didn’t want to write it once for futures-0.1, then futures-0.3, and then put in async/await :/ ________________________________ From: Satyender Yadav (JIRA) <j...@apache.org> Sent: Wednesday, February 13, 2019 10:17 AM To: dev@thrift.apache.org Subject: [jira] [Commented] (THRIFT-4777) Non Blocking Server implementation for Rust [ https://issues.apache.org/jira/browse/THRIFT-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767294#comment-16767294 ] Satyender Yadav commented on THRIFT-4777: ----------------------------------------- Hi [~allengeorge] It turns out that even the thrift generated code for server side to be having code chunks that read from socket. And this is basically a blocking IO. So for the time being I will be doing further dev on the same passively over weekends only. > Non Blocking Server implementation for Rust > ------------------------------------------- > > Key: THRIFT-4777 > URL: https://issues.apache.org/jira/browse/THRIFT-4777 > Project: Thrift > Issue Type: New Feature > Components: Rust - Library > Reporter: Satyender Yadav > Assignee: Allen George > Priority: Minor > > Implement Non blocking server in Thrift rust library. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
