Yes, I would agree with that, weakref is one way of solving that. Haven’t run into a scenario where the thread outlives the caller yet though, but suspect I might.
The result is that you can use bound methods as callbacks, and run your initial logic through a thread pool. Then the callback will be executed in the main thread, but can quietly fail if the owning object was deleted. And it won’t hold a reference to the owning object. The version I posted takes bound methods too, it also runs in the main loop, due to QtCore.Qt.BlockingQueuedConnection <http://doc.qt.io/qt-5/qt.html#ConnectionType-enum>. The remaining difference between our results looks to be that you are limiting thread count; where have you found that to come in handy? Why limit the amount of threads to begin with? How many threads would you end up with otherwise? On 26 March 2015 at 07:23, Justin Israel <justinisr...@gmail.com> wrote: > > On Thu, 26 Mar 2015 7:26 PM Robert White <robert.wd.wh...@gmail.com> > wrote: > > If you're worried about event handlers keeping callback objects alive when > they should have already been wiped out. > > Use the weakref module. > > They have a pretty good example at > http://code.activestate.com/recipes/578298-bound-method-weakref/. > > I ended up using a variation of this for my MSceneMessage handler system. > Been working really well for me. > > That's what my version uses. The callbacks are stored as weakrefs > > > On Wednesday, March 25, 2015 at 2:59:41 PM UTC-5, Justin Israel wrote: > > If I remember correctly, the original motivation for my version was that I > encountered an issue with callbacks where they were methods of objects that > could be deleted before the callback gets a chance to run, and the fact > that holding a reference to the methods would prevent garbage collection > (which also triggers signal/slot auto cleanup, etc). So I had come across > some information about weakref callbacks. I made some modifications to some > examples I had found. The result is that you can use bound methods as > callbacks, and run your initial logic through a thread pool. Then the > callback will be executed in the main thread, but can quietly fail if the > owning object was deleted. And it won't hold a reference to the owning > object. > > > On Thu, Mar 26, 2015 at 8:11 AM Justin Israel <justin...@gmail.com> > wrote: > > > This looks kind of similar to something I did a while back > > https://gist.github.com/justinfx/6183367 > > We even both use the term "invoke" :-) > Mine uses a posted event to the main loop instead of signals and slots. > > > On Thu, 26 Mar 2015 7:39 AM Marcus Ottosson <konstr...@gmail.com> wrote: > > > Hi all, > > I threw something together on a whim and would like your opinion of it. > > Inspired by JavaScript and it’s use of callbacks for IO-bound functions: > > expensiveFunction("argument", function(result) { console.log("The results > are: " + result); }) > > I did this. > > def callback(result): print "The results are: %s" % result > invoke(expensive_function, callback) > > Code here: > https://gist.github.com/mottosso/c20df396f4ecc882b53c > > Question is, is there already a way of doing this? If not, what could be > made better, faster, stronger? I’m calling it “invoke” but I’m sure there’s > already an established term for it, do you know of any? > > Best, > Marcus > > > > > -- > > *Marcus Ottosson* > konstr...@gmail.com > > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to python_inside_maya+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD6jDvWtY39eBEbQVU95HB2T0wF89GHeXSAdHEnUn5yDA%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD6jDvWtY39eBEbQVU95HB2T0wF89GHeXSAdHEnUn5yDA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to python_inside_maya+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/fa3f0627-14a3-43bf-95b9-9ed02bc4d4fa%40googlegroups.com > <https://groups.google.com/d/msgid/python_inside_maya/fa3f0627-14a3-43bf-95b9-9ed02bc4d4fa%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to python_inside_maya+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2fRpf38gaFUFMFYpZ788VEcPrkcAMeCSf3gRLZx-zi%2BQ%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2fRpf38gaFUFMFYpZ788VEcPrkcAMeCSf3gRLZx-zi%2BQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- *Marcus Ottosson* konstrukt...@gmail.com -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCUfjA31XTrquFwm0mY6zAzB2Ctsq%2BUcpehwsnrdvyWNQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
