Login at Kodi Home

flyingrat · (This post was last modified: 2013-05-14, 21:24 by flyingrat.)

I can't get the built-in python callback method onAbortRequested for class xbmc.Monitor to work.

I've been testing several different version of a simple service that starts by initiating the xbmc.monitor class and then just sleeps waiting for an onAbortRequested events. The service starts ok but never receives an onAbortRequested when xbmc is stopping the service. I've been debugging this issue for several days now without success. Sad

Python interface tracing (ENABLE_TRACE_API) is enabled and python lib debugging enabled but haven't been able to actually nail this bastard. I'm getting lost somewhere near the RetardedAsynchCallbackHandler(!) and the callback queue. This is on current master, platform is osx.

Any idea what might be wrong and does anyone got a working example of onAbortRequested running as a service?

python service code, service.py

Code:
import syst be

import time

import xbmc

class ExitMonitor(xbmc.Monitor):

    def onAbortRequested(self):

        print "ExitMonitor: onAbortRequested() -> sys.exit()"

        sys.exit()

m = ExitMonitor()

print "Testing ExitMonitor, sleep(20000)..."

time.sleep(20000)

addon.xml

Code:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>

<addon

  id="service.exitmontor"

  name="Exitmonitor test plugin"

  provider-name="The Exitmonitor Team"

  version="0.1.0">

  <requires>

    <import addon="xbmc.python" version="2.1.0" />

  </requires>

  <extension library="service.py" point="xbmc.service" start="startup">

  </extension>

  <extension point="xbmc.addon.metadata">

    <platform>all</platform>

    <summary lang="en">Exitmonitor Addon Test</summary>

  </extension>

</addon>

This is a part of the xbmc call path when initiating a service stop (inactivate button from the user interface). The python interface call path seems correct but the actual python method onAbortRequested is never called.

Code:
XBPython::StopScript() ->

XBPyThread::stop() ->  g_pythonParser.OnAbortRequested(addon->ID()) 

XBPython::OnAbortRequested:(*it)->OnAbortRequested() -> 

OnAbortRequested() { TRACE; invokeCallback(new CallbackFunction<Monitor>(this,&Monitor::onAbortRequested)); }

...

...

debug log for the stop activity:

Code:
23:17 T:2896765632   DEBUG: NEWADDON Entering bool XBPython::StopScript(const CStdString&)

23:17 T:2896765632    INFO: Stopping script with id: 1

23:24 T:2896765632   DEBUG:  NEWADDON Entering void XBPython::OnAbortRequested(const CStdString&)

23:34 T:2896765632   DEBUG:   NEWADDON Entering void XBMCAddon::xbmc::Monitor::OnAbortRequested()

23:38 T:2896765632   DEBUG:    NEWADDON constructing CallbackFunction<M> 0xf435160

23:40 T:2896765632   DEBUG:    NEWADDON Entering virtual void XBMCAddon::RetardedAsynchCallbackHandler::invokeCallback(XBMCAddon::Callback*)

23:43 T:2896765632   DEBUG:     NEWADDON constructing AsynchCallbackMessage 0x5635b30

23:43 T:2896765632   DEBUG:     NEWADDON Entering XBMCAddon::AsynchCallbackMessage::AsynchCallbackMessage(XBMCAddon::Callback*, XBMCAddon::RetardedAsynchCallbackHandler*)

23:43 T:2896765632   DEBUG:     NEWADDON Leaving XBMCAddon::AsynchCallbackMessage::AsynchCallbackMessage(XBMCAddon::Callback*, XBMCAddon::RetardedAsynchCallbackHandler*)

23:43 T:2896765632   DEBUG:    NEWADDON Leaving virtual void XBMCAddon::RetardedAsynchCallbackHandler::invokeCallback(XBMCAddon::Callback*)

23:43 T:2896765632   DEBUG:   NEWADDON Leaving void XBMCAddon::xbmc::Monitor::OnAbortRequested()

23:43 T:2896765632   DEBUG:  NEWADDON Leaving void XBPython::OnAbortRequested(const CStdString&)

23:48 T:2896765632   ERROR: XBPyThread::stop - script /Users/lars/Library/Application Support/XBMC/addons/service.exitmonitor/service.py didn't stop in 5 seconds - let's kill it

23:48 T:2896765632   DEBUG: NEWADDON Leaving bool XBPython::StopScript(const CStdString&)

23:48 T:2896765632   DEBUG: CGUIMediaWindow::GetDirectory (addons://enabled/xbmc.service)

23:48 T:2896765632   DEBUG:   ParentPath = [addons://enabled/xbmc.service]

23:48 T:2954383360  NOTICE: Thread JobWorker start, auto delete: true

23:48 T:2954915840  NOTICE: Thread BackgroundLoader start, auto delete: false

23:48 T:2954915840   DEBUG: Thread BackgroundLoader 2954915840 terminating

24:18 T:2954383360   DEBUG: Thread JobWorker 2954383360 terminating (autodelete)

debug log for the start activity:

Code:
19:57 T:2956587008   DEBUG: NEWADDON Entering void XBPython::Initialize()

19:57 T:2956587008    INFO: initializing python engine.

19:57 T:2956587008   DEBUG: NEWADDON Leaving void XBPython::Initialize()

19:57 T:2956587008   DEBUG: new python thread created. id=1

19:57 T:2953850880  NOTICE: Thread XBPython start, auto delete: false

19:57 T:2953850880   DEBUG: Python thread: start processing

20:41 T:2953850880   DEBUG: NEWADDON constructing Python::LanguageHook 0xf297c10

20:41 T:2953850880   DEBUG: NEWADDON Entering void XBMCAddon::Python::LanguageHook::RegisterMe()

20:41 T:2953850880   DEBUG: NEWADDON Leaving void XBMCAddon::Python::LanguageHook::RegisterMe()

20:41 T:2953850880   DEBUG: NEWADDON Entering void XBPython::InitializeInterpreter(ADDON::AddonPtr)

20:41 T:2953850880   DEBUG:  NEWADDON Entering PyObject* PythonBindings::xbmc_log(PyObject*, PyObject*, PyObject*)

20:41 T:2953850880   DEBUG:   NEWADDON Entering static XBMCAddon::AddonClass::Ref<XBMCAddon::Python::LanguageHook> XBMCAddon::Python::LanguageHook::GetIfExists(PyInterpreterState*)

20:41 T:2953850880   DEBUG:   NEWADDON Leaving static XBMCAddon::AddonClass::Ref<XBMCAddon::Python::LanguageHook> XBMCAddon::Python::LanguageHook::GetIfExists(PyInterpreterState*)

20:41 T:2953850880   DEBUG:   NEWADDON Entering static void XBMCAddon::LanguageHook::SetLanguageHook(XBMCAddon::LanguageHook*)

20:41 T:2953850880   DEBUG:   NEWADDON Leaving static void XBMCAddon::LanguageHook::SetLanguageHook(XBMCAddon::LanguageHook*)

20:44 T:2953850880  NOTICE: -->Python Interpreter Initialized<--

20:44 T:2953850880   DEBUG:  NEWADDON Leaving PyObject* PythonBindings::xbmc_log(PyObject*, PyObject*, PyObject*)

20:44 T:2896765632   DEBUG: WinSystemOSX: Fullscreen window Xcode obscures XBMC!

20:44 T:2953850880   DEBUG:  NEWADDON Entering PyObject* PythonBindings::xbmc_log(PyObject*, PyObject*, PyObject*)

20:44 T:2953850880   DEBUG:   NEWADDON Entering static XBMCAddon::AddonClass::Ref<XBMCAddon::Python::LanguageHook> XBMCAddon::Python::LanguageHook::GetIfExists(PyInterpreterState*)

20:44 T:2953850880   DEBUG:   NEWADDON Leaving static XBMCAddon::AddonClass::Ref<XBMCAddon::Python::LanguageHook> XBMCAddon::Python::LanguageHook::GetIfExists(PyInterpreterState*)

20:44 T:2953850880   DEBUG:   NEWADDON Entering static void XBMCAddon::LanguageHook::SetLanguageHook(XBMCAddon::LanguageHook*)

20:44 T:2953850880   DEBUG:   NEWADDON Leaving static void XBMCAddon::LanguageHook::SetLanguageHook(XBMCAddon::LanguageHook*)

20:45 T:2953850880   DEBUG:  NEWADDON Leaving PyObject* PythonBindings::xbmc_log(PyObject*, PyObject*, PyObject*)

20:45 T:2953850880   DEBUG: NEWADDON Leaving void XBPython::InitializeInterpreter(ADDON::AddonPtr)

20:45 T:2953850880   DEBUG: Process - The source file to load is /Users/lars/Library/Application Support/XBMC/addons/service.exitmonitor/service.py

20:45 T:2953850880   DEBUG: Process - Setting the Python path to /Users/lars/Library/Application Support/XBMC/addons/service.exitmonitor:/Users/lars/Library/Application Support/XBMC/addons/weather.wunderground/resources/lib/wunderground:/Users/lars/Library/Application Support/XBMC/addons/script.module.simplejson/lib:/Users/lars/Library/Application Support/XBMC/addons/script.module.beautifulsoup/lib:/Users/lars/src/xbmc/xbmc-ffmpeg-version-bump/addons/script.module.pil/lib:/Users/lars/Library/Application Support/XBMC/addons/script.module.buggalo/lib:/Users/lars/Library/Application Support/XBMC/addons/script.module.mechanize/lib:/Users/lars/Library/Application Support/XBMC/addons/script.module.parsedom/lib:/Users/lars/Library/Application Support/XBMC/addons/script.module.elementtree/lib:/Users/lars/src/xbmc/xbmc-ffmpeg-version-bump/addons/script.module.pysqlite/lib:/Users/lars/Library/Application Support/XBMC/addons/service.exitmonitor/lib:/Users/Shared/xbmc-depends/macosx10.8_i386-target/lib/python26.zip:/Users/Shared/xbmc-depends/macosx10.8_i386-target/lib/python2.6:/Users/Shared/xbmc-depends/macosx10.8_i386-target/lib/python2.6/plat-darwin:/Users/Shared/xbmc-depends/macosx10.8_i386-target/lib/python2.6/plat-mac:/Users/Shared/xbmc-depends/macosx10.8_i386-target/lib/python2.6/plat-mac/lib-scriptpackages:/Users/Shared/xbmc-depends/macosx10.8_i386-target/lib/python2.6/lib-tk:/Users/Shared/xbmc-depends/macosx10.8_i386-target/lib/python2.6/lib-old:/Users/Shared/xbmc-depends/macosx10.8_i386-target/lib/python2.6/lib-dynload:/Users/Shared/xbmc-depends/macosx10.8_i386-target/lib/python2.6/site-packages:

20:45 T:2953850880   DEBUG: Process - Entering source directory /Users/lars/Library/Application Support/XBMC/addons/service.exitmonitor

20:45 T:2953850880   DEBUG: Instantiating addon using automatically obtained id of "service.exitmontor" dependent on version 2.1.0 of the xbmc.python api

20:48 T:2953850880   DEBUG: NEWADDON Entering PyObject* PythonBindings::xbmc_XBMCAddon_xbmc_Monitor_New(PyTypeObject*, PyObject*, PyObject*)

20:52 T:2953850880   DEBUG:  NEWADDON Entering static XBMCAddon::AddonClass::Ref<XBMCAddon::Python::LanguageHook> XBMCAddon::Python::LanguageHook::GetIfExists(PyInterpreterState*)

20:52 T:2953850880   DEBUG:  NEWADDON Leaving static XBMCAddon::AddonClass::Ref<XBMCAddon::Python::LanguageHook> XBMCAddon::Python::LanguageHook::GetIfExists(PyInterpreterState*)

20:52 T:2953850880   DEBUG:  NEWADDON Entering static void XBMCAddon::LanguageHook::SetLanguageHook(XBMCAddon::LanguageHook*)

20:52 T:2953850880   DEBUG:  NEWADDON Leaving static void XBMCAddon::LanguageHook::SetLanguageHook(XBMCAddon::LanguageHook*)

20:52 T:2954383360  NOTICE: Thread BackgroundLoader start, auto delete: false

20:52 T:2954383360   DEBUG: Thread BackgroundLoader 2954383360 terminating

21:01 T:2953850880   DEBUG:  NEWADDON constructing Monitor 0xf437560

21:01 T:2953850880   DEBUG:  NEWADDON Entering virtual XBMCAddon::CallbackHandler* XBMCAddon::Python::LanguageHook::GetCallbackHandler()

21:02 T:2953850880   DEBUG:   NEWADDON constructing PythonCallbackHandler 0xf468490

21:02 T:2953850880   DEBUG:   NEWADDON Entering XBMCAddon::Python::PythonCallbackHandler::PythonCallbackHandler()

21:02 T:2953850880   DEBUG:   NEWADDON Leaving XBMCAddon::Python::PythonCallbackHandler::PythonCallbackHandler()

21:02 T:2953850880   DEBUG:  NEWADDON Leaving virtual XBMCAddon::CallbackHandler* XBMCAddon::Python::LanguageHook::GetCallbackHandler()

21:04 T:2953850880   DEBUG:  NEWADDON Entering virtual XBMCAddon::String XBMCAddon::Python::LanguageHook::GetAddonId()

21:04 T:2953850880   DEBUG:  NEWADDON Leaving virtual XBMCAddon::String XBMCAddon::Python::LanguageHook::GetAddonId()

21:06 T:2953850880   DEBUG:  NEWADDON Entering virtual void XBMCAddon::Python::LanguageHook::RegisterMonitorCallback(XBMCAddon::xbmc::Monitor*)

21:06 T:2953850880   DEBUG:   NEWADDON Entering void XBPython::RegisterPythonMonitorCallBack(XBMCAddon::xbmc::Monitor*)

21:10 T:2953850880   DEBUG:   NEWADDON Leaving void XBPython::RegisterPythonMonitorCallBack(XBMCAddon::xbmc::Monitor*)

21:12 T:2953850880   DEBUG:  NEWADDON Leaving virtual void XBMCAddon::Python::LanguageHook::RegisterMonitorCallback(XBMCAddon::xbmc::Monitor*)

21:18 T:2956587008   DEBUG: Thread JobWorker 2956587008 terminating (autodelete)

21:18 T:2953850880   DEBUG:  NEWADDON Entering void PythonBindings::prepareForReturn(XBMCAddon::AddonClass*)

21:18 T:2953850880   DEBUG:   NEWADDON Entering static XBMCAddon::AddonClass::Ref<XBMCAddon::Python::LanguageHook> XBMCAddon::Python::LanguageHook::GetIfExists(PyInterpreterState*)

21:18 T:2953850880   DEBUG:   NEWADDON Leaving static XBMCAddon::AddonClass::Ref<XBMCAddon::Python::LanguageHook> XBMCAddon::Python::LanguageHook::GetIfExists(PyInterpreterState*)

21:18 T:2953850880   DEBUG:   NEWADDON Entering void XBMCAddon::Python::LanguageHook::RegisterAddonClassInstance(XBMCAddon::AddonClass*)

21:21 T:2953850880   DEBUG:   NEWADDON Leaving void XBMCAddon::Python::LanguageHook::RegisterAddonClassInstance(XBMCAddon::AddonClass*)

21:21 T:2953850880   DEBUG:  NEWADDON Leaving void PythonBindings::prepareForReturn(XBMCAddon::AddonClass*)

21:28 T:2953850880   DEBUG: NEWADDON Leaving PyObject* PythonBindings::xbmc_XBMCAddon_xbmc_Monitor_New(PyTypeObject*, PyObject*, PyObject*)

21:28 T:2953850880   DEBUG: NEWADDON Entering PyObject* PythonBindings::xbmc_log(PyObject*, PyObject*, PyObject*)

21:28 T:2953850880   DEBUG:  NEWADDON Entering static XBMCAddon::AddonClass::Ref<XBMCAddon::Python::LanguageHook> XBMCAddon::Python::LanguageHook::GetIfExists(PyInterpreterState*)

21:28 T:2953850880   DEBUG:  NEWADDON Leaving static XBMCAddon::AddonClass::Ref<XBMCAddon::Python::LanguageHook> XBMCAddon::Python::LanguageHook::GetIfExists(PyInterpreterState*)

21:28 T:2953850880   DEBUG:  NEWADDON Entering static void XBMCAddon::LanguageHook::SetLanguageHook(XBMCAddon::LanguageHook*)

21:28 T:2953850880   DEBUG:  NEWADDON Leaving static void XBMCAddon::LanguageHook::SetLanguageHook(XBMCAddon::LanguageHook*)

21:32 T:2953850880  NOTICE: Testing ExitMonitor, sleep(20000)...

21:32 T:2953850880   DEBUG: NEWADDON Leaving PyObject* PythonBindings::xbmc_log(PyObject*, PyObject*, PyObject*)

21:32 T:2953850880   DEBUG: NEWADDON Entering PyObject* PythonBindings::xbmc_log(PyObject*, PyObject*, PyObject*)

21:32 T:2953850880   DEBUG:  NEWADDON Entering static XBMCAddon::AddonClass::Ref<XBMCAddon::Python::LanguageHook> XBMCAddon::Python::LanguageHook::GetIfExists(PyInterpreterState*)

21:32 T:2953850880   DEBUG:  NEWADDON Leaving static XBMCAddon::AddonClass::Ref<XBMCAddon::Python::LanguageHook> XBMCAddon::Python::LanguageHook::GetIfExists(PyInterpreterState*)

21:32 T:2953850880   DEBUG:  NEWADDON Entering static void XBMCAddon::LanguageHook::SetLanguageHook(XBMCAddon::LanguageHook*)

21:32 T:2953850880   DEBUG:  NEWADDON Leaving static void XBMCAddon::LanguageHook::SetLanguageHook(XBMCAddon::LanguageHook*)

21:34 T:2953850880   DEBUG: NEWADDON Leaving PyObject* PythonBindings::xbmc_log(PyObject*, PyObject*, PyObject*)

**garbear** · 2013-05-14, 03:12

Ready for a mindf*ck? Smile

Change time.sleep(20000) to xbmc.sleep(20000000) and let me know if anything happens.

flyingrat · 2013-05-14, 21:20

(2013-05-14, 03:12)garbear Wrote: Ready for a mindf*ck? Change time.sleep(20000) to xbmc.sleep(20000000) and let me know if anything happens.

Sorry, same thing.

I've booth enabled traceing with PYTHONDEBUG / PYTHONVERBOSE as well as hooking into the python internals with the debugger and breakpoints at the innermost core function PyCFunction_Call() (methodobject.c) which handles all python function calls. I can follow all startup calls but nothing during shutdown of the service thus i can't see any callback activity from xbmc to python from XBMCAddon::xbmc::Monitor::OnAbortRequested() and XBMCAddon::AddonCallback::invokeCallback(XBMCAddon::Callback).

I found this suspicious comment down below that might be interesting to follow up and I also noticed that quite a few changes has been made to the xbmc/interface about 12 days ago thus it's probably worth validating how things are working with an older rev and also with 12.2. I'm not an python interface expert and need some advice how to proceed, so any other ideas?

xbmc/interfaces/legacy/CallbackHandler.cpp #L42

Code:
//********************************************************************

  // This holds the callback messages which will be executed. It doesn't

  //  seem to work correctly with the Ref object so we'll go with Ref*'s

  typedef std::vector<AddonClass::Ref<AsynchCallbackMessage> > CallbackQueue;

  //********************************************************************

  static CCriticalSection critSection;

  static CallbackQueue g_callQueue;

  void RetardedAsynchCallbackHandler::invokeCallback(Callback* cb)

  {

    TRACE;

    CSingleLock lock(critSection);

    g_callQueue.push_back(new AsynchCallbackMessage(cb,this));

  }

**Martijn** · 2013-05-14, 21:27

For starters never ever put log or snippet on the forum but use pastebin.com or whatever

flyingrat · (This post was last modified: 2013-05-14, 21:55 by flyingrat.)

(2013-05-14, 21:27)Martijn Wrote: For starters never ever put log or snippet on the forum but use pastebin.com or whatever

Thank you MK, i wasn't aware there was a "snippet rule" on this forum! Tongue

So, what is the current maxline for a snippet? Wink

flyingrat · (This post was last modified: 2013-05-14, 21:56 by flyingrat.)

(2013-05-14, 03:12)garbear Wrote: Ready for a mindf*ck? Change time.sleep(20000) to xbmc.sleep(20000000) and let me know if anything happens.

Btw Garbear, if possible would you mind testing the same service code at your end to check if you get a similar behavior. /Thanks, Lars.

**garbear** · 2013-05-16, 06:49

Well it was worth a try. I ran into the same problem with xbmc.Player callbacks here while working on PR2499. Given my findings, I'm pretty sure you'll need to avoid system sleeps and rely on xbmc.sleep() or blocking calls like xbmc.dialog.DoModal(). onAbortRequested() still doesn't work though, so maybe we broke something :p I'll test it out tomorrow.

flyingrat · (This post was last modified: 2013-05-16, 22:23 by flyingrat.)

Done some hard core debugging with a lot of trial-n-error and have now tested most of the important python subsystems (io, file, sys, socket, exceptions, sysexit, threads, etc) and it seems that python environment is totally locked down or is uncallable during callback to xbmc.moniotor.onAbortRequested thus trying to do something useful in there is quite pointless (for now).

Currently, the only working method is polling the attribute xbmc.abortRequested which is 1) totally unnecessary consumption of cpu power, especially in regards of low power devices like RPi, surf-pads and smartphones 2) is really ugly! and 3) belongs in the stone age IMPO Smile

thus in other words, i think it's important we can get this issue fixed.

I'm still trying find out a working solution and here is a hint where i'm at right now: "GIL and non-python-created-threads". This is also interesting "Asynchronous Notifications" (python 2.7).

Bstrdsmkr · 2013-05-17, 04:34

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()

**garbear** · 2013-05-17, 06:25

But Bstrdsmkr, it's the principle that matters Wink

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.

flyingrat · (This post was last modified: 2013-05-17, 08:57 by flyingrat.)

(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 ( Confused

hudder:

) 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! Smile

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?

Bstrdsmkr · 2013-05-17, 17:23

(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 (hudder: 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

flyingrat · (This post was last modified: 2013-05-19, 22:48 by flyingrat.)

(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 (hudder: 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.