<br><br><div class="gmail_quote">On Thu, Oct 30, 2008 at 3:21 PM, Corin Langosch <span dir="ltr"><<a href="mailto:corinl@gmx.de">corinl@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<tt>Hi Raghavendra,<br>
<br>
thank's for the explanations, I think I now got it :)<br>
<br>
Here's a simple example of what I expect to happen, from a client-side
view:<br>
<br>
fuse_request -> unify_lookup -> node1_lookup -> protocoll
-> network_send<br>
-> node2_lookup -> </tt><tt>protocoll
-> network_send</tt><br>
<tt>(this actually does nothing than setting up the stack and sending
the request to the server) <br>
<br>
network_in -> protocoll -> stack_lookup_and_call_cbk ->
node2_lookup -> unify_lookup -> (no unwind, since we need two
responses/calls)<br>
network_in -> protocoll -> stack_lookup_and_call_cbk ->
node1_lookup -> unify_lookup -> fuse_request<br>
</tt><tt>(order of node1 and node2 may vary, depeding on their reply
speed)<br>
</tt><br>
<tt>side note:<br>
the individual stack_cbks itself only call unwind when they are fully
done, otherwise they'll stay on the stack and will so be called when
more data arrives.<br>
<br>
So the most important thing is that all functions are 100%
non-blocking. Functions which can't avoid this (like those doing system
calls which block) must be implemented behind a thread-manager which
actually transfers blocking to non-blocking operations.<br>
<br>
So everything looks quite good for me now. But looking at the
io-threads xlater puzzled me again a bit. Fox eample the iot_open
directly calls fops->open (so posix_open normally) which will block.
The iot_schedule is done in the iot_open_cbk, which is called when
posix_open finished it's work.</tt></div></blockquote><div><br>io-threads starts serializes all operations on an inode, when an open() is done on an inode. hence schedule() happens in {open,create}_cbk()<br><br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><tt><br>
<br>
But what I'd expect iot_open to do is not to call the fops->open
directly but instead pass it to a worker thread of it's pool. This
thread will handle the fops->open and call iot_open_cbk (so passing
the data down the whole stack) when done. And this is correctly done in
all other fops like iot_close, iot_read...?</tt></div></blockquote><div><br>before the first open() call on an inode, there won't be a scheduled worker thread for any file. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><tt><br>
<br>
Corin<br>
<br>
</tt>Am 30.10.2008 05:09, Raghavendra G schrieb:
<div><div></div><div class="Wj3C7c"><blockquote type="cite">Hi Corin,<br>
<br>
STACK_WIND and STACK_UNWIND are analogous to C procedure call and
return from it. But, the major difference is that in C when a return is
done from a procedure, the control is returned to the calling
procedure, but when a STACK_UNWIND is done, the control is returned to
the procedure provided as an argument to STACK_WIND macro (the "cbk"
argument). The STACK_WIND macro stores the "context" (call back
procedure etc) necessary to do this. A series of STACK_WIND macros
results in a stack of these contexts built on heap and the
corresponding STACK_UNWINDs results in unwinding of this stack (Note
that the stack built due to calls to STACK_WIND is different from the C
function stack, which is cleared as soon as the C function returns. But
the "context"/stack built by STACK_WIND is preserved across C
functions). <br>
<br>
In other words, STACK_WIND/STACK_UNWIND implements continuations
(provided by lisp and other languages) for glusterfs in C.<br>
<br>
These two macros are among the basic building blocks of glusterfs'
asynchronous model of operation.<br>
<br>
STACK_WIND/STACK_UNWIND pair of macros helps to handle the operations
across the network (say between client and server) asynchronously. The
request/reply for/to an operation is written to network, but the
glusterfs is not blocked until the response is returned. Instead it
"pauses the current operation" and continues to act upon requests for
other operations. When the response is got, the corresponding "paused
operation" is resumed using the stack built by series of STACK_WINDs
till the request/reply was written to network.<br>
<br>
regards,<br>
<br>
<div class="gmail_quote">On Thu, Oct 30, 2008 at 2:58 AM, Corin
Langosch <span dir="ltr"><<a href="mailto:corinl@gmx.de" target="_blank">corinl@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<br>
I just looked some time at the code but I think I just didn't get the<br>
usage of STACK_WIND / STACK_UNWIND right.<br>
<br>
Looking at the macros and the translators (for example), STACK_WIND<br>
simply seems to setup some datastructures and then call the suplied<br>
function. After that function is done, the MACRO is done and code<br>
executions continues normal.<br>
<br>
So if I put a STACK_WIND into a loop (like in unify) the function passed<br>
in the MACRO is simply called. So the calls don't happen in parallel but<br>
normal seriazliezd, as they would have happened without using<br>
STACK_WIND. So what is STACK_WIND all about - for me it currently seems<br>
to be for passing (some common) data between function calls. It doesn't<br>
execute any functions in parallel in order to reduce latencies caused by<br>
the backends?<br>
<br>
The function call in the STACK_UNWIND macro puzzles me even more. What<br>
is this for? As the STACK_UNWIND function is called from within the<br>
function called by STACK_WIND, I'd suspect some kind of loop?<br>
<br>
What's about with the while(0) inside the macros. They don't do
anything? ;)<br>
<br>
Thanks for any clarifications :)<br>
Corin<br>
<br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org" target="_blank">Gluster-devel@nongnu.org</a><br>
<a href="http://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">http://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Raghavendra G<br>
<br>
</blockquote>
</div></div></div>
<br>_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a href="http://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">http://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>hard work often pays off after time, but laziness always pays off now<br>