On 01/06/2015 12:17 AM, Mike Christie wrote:
Was the last issue the case where if actor_schedule_private gets 0 for
delay_secs or does that just work?
Not sure I quite follow but actor_schedule_private with 0 for delay_secs
should be fine -- the actor is put on the ready_list straightaway and
will be run the next time actor_poll() is called.
For example when we do: iscsi_sched_ev_context() handles
EV_CONN_RECV_PDU event -> actor_schedule() -> actor_schedule_private().
In that type of case, what would force us to always handle that event/actor?
Does it currently work because we would normally get an event indicating
we have got something like a nl message and handle it here:
if (poll_array[POLL_CTRL].revents)
ipc->ctldev_handle();
The nl handling code in ctldev_handle would call
iscsi_sched_ev_context() and put the actor on the actor linked list. We
would then reloop:
while (1) {
....
and then call
actor_poll();
where the actor would be handled.
Is the only problem case if that actor handler then wanted to call
actor_schedule(), because we could then fall into the poll() call
passing -1 if there was nothing to reap? I am checking out the code now
to see if this can ever happen.
An executing actor can call actor_schedule() (either with a zero or
nonzero delay) to run another actor. If the delay is zero then the new
actor will be run before the current invocation of actor_poll() exits.
If the delay is nonzero then it would be put on the pend_list and we'd
set the alarm to exit the poll() and re-call actor_poll() when it is due.
-- Andy
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
