<br><br><div class="gmail_quote">On Wed, Sep 26, 2012 at 1:55 AM, Gustavo Bervian Brand <span dir="ltr"><<a href="mailto:gugabrand@gmail.com" target="_blank">gugabrand@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<div><br></div><div> Some days ago when I mentioned I was using syncop_*() calls and Avati asked if I was triggering them from a synctask worker.</div><div> </div><div> By what I can see the synctask_new will create a new thread each time, so if want a real syncronous execution from within a sequence of readv calls, creating a synctask at each readv doesn't seem a good way to go because the order of execution of these threads is not guaranteed to be sequential.</div>
<div><br></div>
<div> So, my question is why the syncop calls wouldn't be ok to be executed outside a synctask worker in this scenario (or any other)? </div><div> I didn't find any documentation about this, so that's why I am asking.</div>
<div><br></div></blockquote><div><br></div><div>Synctasks use pre-running syncproc threads to schedule the task. The normal FOPs are asynchronous in nature (i.e, a STACK_WIND return is only the return of a submission, not the return of the operation). Syncops give you a synchronous wrapper around the fundamentally asynchronous calls. For this they either block the calling thread (which is very dangerous if the thread calling syncop is the poll thread), or, when executed within a synctask (in a syncenv), utilize setcontext/getcontext to give the "feeling" of a blocked thread.</div>
<div><br></div><div><br></div><div>Avati</div><div><br></div><div><br></div></div>