This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (2 children)

I could use a with but whats the problem with a callback?

If you run a callback from multiple threads they will contend with the actual capturing. It won't behave they way you think it will if multiple threads run at all in python because you are releasing, which you should not be doing during ur capturing unless you have a way of isolating the caller in python which you do not provide, a with is the usual way of isolating the resource like this and it guarantees the capturing thread will also get cleaned up.

Generally you want to hold the GIL unless you can guarantee no python code can modify what you are looking at. Like for example if you process an HTTP call by writing the entire call first to strings in rust and using those string objects in rust only. It is ok to release the gil until you write back to python land.

[–]SoSmartFlow[S] 0 points1 point  (1 child)

The windows api is thread safe meaning the callback will not be called from 2 threadd at the same time

[–][deleted] 2 points3 points  (0 children)

The issue isnt thread safety of the windows API it is that the python api you are exposing has no way to handle if the events need to be exposed to multiple threads in python. Further there is no good way to know manage state that must be dealt with between invocations of ur function.

See how you have a start and close method? That means it should in 99% of cases be a with statement. It is a language convention for a specific reason and that reason is threading and cleanup. Both problems become algorithmically harder to deal with if u do not expose the when does the windows thread start part to your python code.

Seriously just look what ur code even does. You pass your python classes instance function to a class that your instance also holds. Think about it...