On 14 Aug 2009 at 15:08, Hannes Reinecke wrote:

> Ulrich Windl wrote:
> > On 13 Aug 2009 at 11:55, Mike Christie wrote:
> > 
> >> some additions:
> >>
> >>
> >> Mike Christie wrote:
> >>> wait_on_commands()
> >>> {
> >>    while (check_restrictions(conn->task) &&
> >>            session->state == LOGGED_IN)
> >>            wait for a while
> > 
> > "wait for a while" always looks like a design flaw to me. Wait for what?
> > 
> For the xmit thread to catch up. Due to the asynchronous nature the
> xmit thread is independent on the error handler thread, so the
> eh thread has to be synchronized here until the xmit thread has processed
> all outstanding commands.

But who makes sure "a while" is long enough? It seems you are just releasing a 
mutex lock, then re-aquire it. If the lock does fair queuing, you don't need to 
wait; you'd just have to do something like "sched_yield()" (for kernel tasks). 
I understood it well, you want to enforce a "task switch" inside the kernel. 


You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to