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).
If
I understood it well, you want to enforce a "task switch" inside the kernel.
Right?
Regards,
Ulrich
--~--~---------~--~----~------------~-------~--~----~
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
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---
