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 open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.