xbmc interface callback to python onAbortRequested fails

(2013-05-17 04:34)Bstrdsmkr Wrote:  Can't you do something like this in a service?

Code:

import

while not xbmc.abortRequested:
    xbmc.sleep(10000)

# At this point we know a shutdown has started so...
do_stuff()

Unfortunately not if you want to shutdown a service gracefully within 5 seconds (standard xbmc time out period). This affects all addons that are waiting for system resources like accept, socket stream i/o, rpc locks, file locks, pipe read/write, etc. I think that's the reason why most add-ons still are using poll loops (:shudder: ) instead if being event driven...

---

(2013-05-17 06:25)garbear Wrote:  But Bstrdsmkr, it's the principle that matters Sorry flyingrat, didn't get a chance to test it out today. I've already spent some time on this issue with the xbmc.Player callbacks, so I'd like to follow up and see if I can't figure out the abort problem also. I'll try to nail down the issue for good on Sunday.

No problem, i'm still fighting to figure out the root cause and a possible solution! What was the problem with the xbmc.Player callbacks? Btw, i'm wondering if this might be a platform specific problem. I get this issue on osx so i'll try another platform on sunday. What platform are you on?

(2013-05-17 06:25)garbear Wrote:  But Bstrdsmkr, it's the principle that matters Sorry flyingrat, didn't get a chance to test it out today. I've already spent some time on this issue with the xbmc.Player callbacks, so I'd like to follow up and see if I can't figure out the abort problem also. I'll try to nail down the issue for good on Sunday.

heh, I know, just trying to get him a working solution so it doesn't block his development until it's fixed

flyingrat Wrote:Unfortunately not if you want to shutdown a service gracefully within 5 seconds (standard xbmc time out period). This affects all addons that are waiting for system resources like accept, socket stream i/o, rpc locks, file locks, pipe read/write, etc. I think that's the reason why most add-ons still are using poll loops (:shudder: Wink) instead if being event driven...

Yeah polling just feels dirty, but so does having to relaunch your addon and check parameters to do anything lol
It requires more hoop-jumping than the monitor class, but I'm having trouble seeing a situation where you couldn't use xbmc.onAbortRequested.
Edit: I'm just now seeing your post about it being possible this way

flyingrat Wrote:What was the problem with the xbmc.Player callbacks?

Xbmc uses an internal queue to activate callbacks, which is advanced during xbmc.sleep() or when no other python process is in focus. time.sleep() blocks so the queue doesn't advance until the sleep is complete, then the callbacks are executed

(2013-05-17 17:23)Bstrdsmkr Wrote:  

(2013-05-17 06:25)garbear Wrote:  But Bstrdsmkr, it's the principle that matters Sorry flyingrat, didn't get a chance to test it out today. I've already spent some time on this issue with the xbmc.Player callbacks, so I'd like to follow up and see if I can't figure out the abort problem also. I'll try to nail down the issue for good on Sunday.

heh, I know, just trying to get him a working solution so it doesn't block his development until it's fixed

flyingrat Wrote:Unfortunately not if you want to shutdown a service gracefully within 5 seconds (standard xbmc time out period). This affects all addons that are waiting for system resources like accept, socket stream i/o, rpc locks, file locks, pipe read/write, etc. I think that's the reason why most add-ons still are using poll loops (:shudder: Wink) instead if being event driven...

Yeah polling just feels dirty, but so does having to relaunch your addon and check parameters to do anything lol
It requires more hoop-jumping than the monitor class, but I'm having trouble seeing a situation where you couldn't use xbmc.onAbortRequested.
Edit: I'm just now seeing your post about it being possible this way

Aha, sorry it seems that i missed to supply adequate background information on this particular case. Please check this link for some more details and then read on: "http://forum.xbmc.org/showthread.php?tid=116496&pid=1412377#pid1412377"

Thus my main concern is background cpu consumption on low power devices with weaker processors (i.e. SoC with ARM). For instance if you only have just 1-2% idle in on a regular pc/mac it may well end up like 25-30% on a rpi or ipad. Let's say you want to develop a responsive network service and are forced to use polling (i.e non blocking i/o) with a service that is waiting for active connections or want to read data from a socket. Then you need to decide how quickly you want to react to a network call in relation to the poll frequency and how much system resource you are willing to consume during idling when polling either accept(2) or a socket read(2).

(2013-05-17 17:23)Bstrdsmkr Wrote:  

flyingrat Wrote:What was the problem with the xbmc.Player callbacks?

Xbmc uses an internal queue to activate callbacks, which is advanced during xbmc.sleep() or when no other python process is in focus. time.sleep() blocks so the queue doesn't advance until the sleep is complete, then the callbacks are executed

That was useful and interesting info, thanks! I'm not sure yet but it may well be the same root case. I'll try to use xbmc.sleep() with shorter sleep period to see if that will advance the callback queue. I suspect "Asynchronous Notifications" that was introduced in Python v2.7 may be a possible solution for this kind of problem...

/Cheers, Lars.