Python: save reference to a thread
#16
(2014-10-21, 16:02)takoi Wrote: You should try to explain the problem you are trying to solve in a more general way, or reconsider showing that code, because the question of how "to save a reference to a thread" doesn't make much sense. I don't think reference and thread means what you think it means.

I think it does:

Is there a way to save a reference to a thread?

Wink

Or maybe it should be: saving a reference of a thread?
Reply
#17
(2014-10-19, 15:24)GreenAir Wrote: I don't know if i'm allowed to talk about it because it is for streaming movies and TV-shows.
It is legal here in Switzerland but I'm not familiar with the guidelines here in the forum.

Perhaps you can find a legitimate add-on (from xbmc's repo) that behaves the same way, and then any code changes can be discussed more freely here.
Obviously once the best solution for the legitate add-on is found you can apply the same technique to other add-ons.

It's worth being aware that imported python source files (.py) are compiled into byte code (.pyc or .pyo) when first run.
Subsequent runs will be quicker than the first run as this set is already done.

*However* the top level python file (default.py, services.py etc) is recompiled to byte code every time.
Only imported files get saved as byte code.

This means an add-on that has a lot of code in default.py will be slow to launch every time.
If default.py just imports another module that contains the same code, then it will load quicker (by utilising the .pyc/.pyo file).
Reply
#18
(2014-10-21, 16:18)GreenAir Wrote: I think it does:

Is there a way to save a reference to a thread?

Wink
If you want to have it that way, you asked for itWink, here's how you save a reference to a thread:
Code:
t = threading.current_thread()
t is now a reference to a thread. Problem solved?
Reply
#19
(2014-10-21, 16:28)takoi Wrote: If you want to have it that way, you asked for itWink, here's how you save a reference to a thread:
Code:
t = threading.current_thread()
t is now a reference to a thread. Problem solved?

Almost, now I only need a way to save that reference (say to a file) so I can load it later and interface with the still running thread.
Reply
#20
Could you not use an invisible setting that is saved to settings.xml in addon_data?

xbmcaddon.Addon(id=ID).setSetting(param, str(value))

Where ID is:

ID = 'plugin.video.yourplugin'
Reply
#21
(2014-10-21, 17:00)DixieDean Wrote: Could you not use an invisible setting that is saved to settings.xml in addon_data?

That is good idea, that is actually how I made it initially, but somehow it used too much CPU, read through the posts how I found another way.

I posted the code here: Video addon performance on Pi #50
Reply
#22
(2014-10-21, 16:27)popcornmix Wrote: *However* the top level python file (default.py, services.py etc) is recompiled to byte code every time.
Only imported files get saved as byte code.

This means an add-on that has a lot of code in default.py will be slow to launch every time.
If default.py just imports another module that contains the same code, then it will load quicker (by utilising the .pyc/.pyo file).

Pure gold. I did not know that. That explains those addons where the default.py is 5 lines calling another script.
Reply
#23
(2014-10-21, 22:33)Karnagious Wrote: Pure gold. I did not know that. That explains those addons where the default.py is 5 lines calling another script.

If you spot any add-ons with a huge default.py then it's worth nudging the author.
I suspect a lot of python coders are unaware of this (as I was until recently).
Reply
#24
(2014-10-21, 16:54)GreenAir Wrote:
(2014-10-21, 16:28)takoi Wrote: If you want to have it that way, you asked for itWink, here's how you save a reference to a thread:
Code:
t = threading.current_thread()
t is now a reference to a thread. Problem solved?

Almost, now I only need a way to save that reference (say to a file) so I can load it later and interface with the still running thread.

When the script is launched the next time it gets a new global context, so the thread you saved is in another context. i.e. you have _no_ way to contact it directly through normal means.

SO you need do use some inter process messaging, which you could do through sockets or through files.
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#25
(2014-10-21, 17:28)GreenAir Wrote:
(2014-10-21, 17:00)DixieDean Wrote: Could you not use an invisible setting that is saved to settings.xml in addon_data?

That is good idea, that is actually how I made it initially, but somehow it used too much CPU, read through the posts how I found another way.

I posted the code here: Video addon performance on Pi #50
You see? It's imitatively obvious why you are experience it as being slow. You are communicating via setting/polling window properties! It looks like this is the same program, so why are you even using threads and properties and not, you know, variables..
Reply
#26
(2014-10-22, 10:44)topfs2 Wrote: When the script is launched the next time it gets a new global context, so the thread you saved is in another context. i.e. you have _no_ way to contact it directly through normal means.

SO you need do use some inter process messaging, which you could do through sockets or through files.

Now we are on the right track, maybe there are 'non-normal means' to directly interact with the other context?

like saving the address of the thread function and typecasting it on the next run...

Again: I don't know python Angel

(2014-10-22, 11:05)takoi Wrote: It's imitatively obvious why you are experience it as being slow. You are communicating via setting/polling window properties!

Sorry, I wasn't clear about that, the code I posted is how i made the plugin faster (0.1s vs 2-3s)
It's just not nice with the window property polling.
Reply
#27
Just for information. xbmcswift2 plugin framework provides persistent storage among other nice features Smile
Reply
#28
(2014-10-22, 11:20)GreenAir Wrote:
(2014-10-22, 10:44)topfs2 Wrote: When the script is launched the next time it gets a new global context, so the thread you saved is in another context. i.e. you have _no_ way to contact it directly through normal means.

SO you need do use some inter process messaging, which you could do through sockets or through files.

Now we are on the right track, maybe there are 'non-normal means' to directly interact with the other context?

like saving the address of the thread function and typecasting it on the next run...

Again: I don't know python Angel

IF you get access outside you context you are probably hitting a bug in python. Do it proper or don't do it.

There are a bunch of interprocess libraries. Xbmc doesn't provide anything here (we probably should though)

A popular one is zeromq. Not sure if any addon uses it though.
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#29
(2014-10-22, 14:38)topfs2 Wrote: IF you get access outside you context you are probably hitting a bug in python. Do it proper or don't do it.

There are a bunch of interprocess libraries. Xbmc doesn't provide anything here (we probably should though)

A popular one is zeromq. Not sure if any addon uses it though.

Thank you, that's the answer I was looking for.
Even if it's 'it's not possible and if you find a way: don't do it!' Wink

Maybe interprocess access is not the best way, probably would be safer and cleaner with a fast form of communication like you discussed here
Reply

Logout Mark Read Team Forum Stats Members Help
Python: save reference to a thread0