Kodi Community Forum

Full Version: Python Callback handling in XBMC
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Well,

In the process of trying to figure this out, I'm a bit confused by the codebase and was hoping someone might be able to answer a question or three.

It appears that "MakePendingCalls" (which delivers the callback invocation to the Python code) is only issued from a "xbmx.Sleep" or a Window.DoModal() call. I cannot follow how callbacks generally make it into the Python side other than having a Sleep or DoModal issued from the python code. I find this odd and think I'm missing something.

I find this strange because it appears that the calls are made asynchronously from the C side but can only be received when one of these two calls are made from the Python side.

I guess my questions are:

1) Is this a correct understanding?
2) If so, is this the desired behavior? If not, I can think about how to make this work in a (more) truly asynchronous manner (I understand the Python limitations on multi-threaded code and what needs to be done to handle the InterpreterState and ThreadState).
3) Is there a desire to implement synchronous callbacks from the C side? That is, the call issued from the C side wont return until the Python addon has handled it and responded. If so, I can think about how to make that work - even given the Python multithreading limitations.

Thanks
Jim
1. I believe so, yes. It kinda makes sense - you need to have a script running in order to detect the callback anyway, which requires either a modal dialog/window or an explicit while(1) { sleep(1); } type loop.

2. Not necessarily desired - if you can get it working without the hackery (or with a better form of hackery), then all the better. One presumes that the script still needs to be "running" in some manner either way.

3. That would be useful, yes. In particular for action handling and the like - we currently can't check whether python has handled an action or whether it needs to be handled by the general window class for instance. We thus do both at present, and return based on what the general window class gives (as that is the only thing that is synchronous.)

Cheers,
Jonathan