[
https://issues.apache.org/jira/browse/THRIFT-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671645#action_12671645
]
erikfrey edited comment on THRIFT-311 at 2/8/09 9:00 AM:
----------------------------------------------------------
I think a thread pool that does i/o and runs the processor (your current
design) is the best/most asio-y way to go. If you make a separate thread pool
to process requests, you're just shifting from a queue that backs up on i/o to
a queue that backs up on tasks.
I would love to see a coroutine thrift server, if just to see the raw
throughput it could pump out :) There's a boost vault project called
boost.coroutine ( http://www.crystalclearsoftware.com/soc/coroutine/index.html
) that plays pretty nicely with asio. If used properly, you could probably
write a coroutine socket class that behaved like a blocking socket, but used
coroutine under the hood to yield for any i/o.
My main concern with coroutines is how nicely they would play with concurrency
in the user's processor code. Usual mutex/thread type stuff would not work!
Have you tried benchmarking against TNonBlockingServer? I'm curious how they
compare, particularly on multi-core.
was (Author: erikfrey):
I think a thread pool that does i/o and runs the processor (your current
design) is the best/most asio-y way to go. If you make a separate thread pool
to process requests, you're just shifting from a queue that backs up on i/o to
a queue that backs up on tasks.
I would love to see a coroutine thrift server, if just to see the raw
throughput it could pump out :) There's a boost vault project called
<a
href="http://www.crystalclearsoftware.com/soc/coroutine/index.html";>boost.coroutine</a>
that plays pretty nicely with asio. If used properly, you could probably
write a coroutine socket class that behaved like a blocking socket, but used
coroutine under the hood to yield for any i/o.
My main concern with coroutines is how nicely they would play with concurrency
in the user's processor code. Usual mutex/thread type stuff would not work!
Have you tried benchmarking against TNonBlockingServer? I'm curious how they
compare, particularly on multi-core.
> ASIO client & server
> --------------------
>
> Key: THRIFT-311
> URL: https://issues.apache.org/jira/browse/THRIFT-311
> Project: Thrift
> Issue Type: Sub-task
> Components: Library (C++)
> Reporter: Esteve Fernandez
> Attachments: thrift_connection.cpp, thrift_connection.hpp,
> thrift_handler.cpp, thrift_handler.hpp, thrift_main.cpp, thrift_server.cpp,
> thrift_server.hpp, ThriftCalculatorASIOServer.cpp
>
>
> Given the recent discussion on a Windows port and moving to ASIO
> (http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/200901.mbox/%[email protected]%3e),
> I decided to hack a little Thrift asynchronous prototype server using ASIO
> and here's the result. It implements the Calculator service that can be found
> in the tutorial and, just like TNonblockingServer, it uses a FramedTransport.
> It's just a quick prototype, but I think it's enough for building a more
> generic server/protocol. I've only tested it in Linux, but I think there's
> nothing platform-dependent and can be compiled "as is" in Windows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
