[Gluster-devel] How does GD_SYNCOP work?

[Santosh Pradhan]

On 09/11/2014 10:11 AM, Krishnan Parthasarathi wrote:
> Emmanuel,
>
> The scheduling of a paused task happens when the epoll thread receives a POLLIN event along with
> the response from the remote endpoint. This is contingent on the fact that the call back must issue
> a synctask_wake, which will trigger the resumption of the task (in one of the threads from the syncenv).
> In summary, the call back code triggers the scheduling back of the paused task.

Does this whole framework work with poll() interface (not epoll() 
interface)? If yes, it should work in BSD flavours. If it needs epoll() 
then it may not work in BSD flavoured ones which does not have epoll() 
which is pointed out by Emmanuel. Though have a robust kqueue() which 
may need some work.

BR,
Santosh

>
> HTH,
> KP
>
> ----- Original Message -----
>> On Wed, Sep 10, 2014 at 05:32:41AM -0400, Krishnan Parthasarathi wrote:
>>> Let me try to explain how GD_SYNCOP works. Internally, GD_SYNCOP yields the
>>> thread that was
>>> executing the (sync)task once the RPC request is submitted (asynchronously)
>>> to the remote endpoint.
>>> It's equivalent to pausing the task until the response is received. The
>>> call back function, which generally
>>> executes in the epoll thread, wakes the corresponding task into execution
>>> (ie. resumes task execution).
>> I suspect this is the problem: the task is not scheduled. NetBSD uses poll
>> and not epoll,
>> which may explain the problem. Where does the task scheduling happens in
>> epoll code?
>> --
>> Emmanuel Dreyfus
>> manu at netbsd.org
>>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel