|
From: | Krishnan Parthasarathi |
Subject: | Re: [Gluster-devel] rpc problems when using syncops in callbacks |
Date: | Mon, 29 Apr 2013 17:27:43 +0530 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
Fog,
I hope I have caught your attention before you have decided to start over using STACK_WIND/STACK_UNWIND (async way) macros and drop the syncop approach. On 04/29/2013 05:03 PM, fog - wrote: Making the fop use the synctask framework DOESN'T mean you are going to spawn a new thread everytime!It actually means you are scheduling another task into the synctask environment. All you need to ensure is that you don't 'yield' while on the epoll thread. You could take a look at how mgmt/glusterd[1] xlator uses the synctask framework to provide synchronous wrappers to the mgmt operations. In glusterd, the rpc programs have been marked for using synctask at the rpcsvc layer. What this means is, that each rpc request would be run in a synctask and the epoll thread returns to listening for newer network events. In this approach, you have the guarantee that epoll is not held hostage when you yield (never!). And all your code looks pretty and synchronous. This approach may not work too well for you. But I am just saying how I got across the synctask 'barrier' (pun not intended) while making glusterd's mgmt operations (appear) synchronous. [1] - xlators/mgmt/glusterd/src/glusterd-syncop.c HTH, krish
|
[Prev in Thread] | Current Thread | [Next in Thread] |