On Wed, Apr 8, 2015 at 2:51 AM Marcus Ottosson <konstrukt...@gmail.com> wrote:
> Hey Justin, > > I've been using Invoke now since we last spoke of it and things have been > going quite well, and I haven't yet seen the need to limit the amount of > threads running within the application with a thread pool. > Right, it just depends on how your app is structured. An example would be if your app listening to external triggers of some sort and does work. Since you have no control over these triggers, you could have unbounded threads being launched. So in that circumstance a threadpool would give you some form of control. Also, normally one does work in a background thread if it is something that will take some time and would block the main gui thread. So if it is possible that there are triggers within your own application that can schedule multiple requests, then it would also make sense to bound it in some way. Anyways, if you didn't need it in your app, then its totally understandable. > > But I have gotten another problem for which a thread pool might be > helpful, which is managing the order in which threads finish. > > What's happening now is that threads are spawned independently of each > other and finishes whenever they finish, and even though I have no > immediate coupling between them, I do get some rather odd unexplainable > things happening - particularly related to the creation and destruction of > objects that are somehow managed by separate threads. > > I'm suspecting it may be due to one thread finishing, calling back to the > main thread to perform some function, but as it performs, another thread > finishes and makes an update to the same data structure. > > Either way, what I was thinking is that a thread pool could be the > solution to this, while also making the implementation easier to > understand. I'd simply have a single threadpool, with a single worker, and > pass all work to it. I would still get asynchronousy, which is the only > goal, but with synchronous behaviour. > > The point is of course null if multiple workers are introduced, so was > wondering what your thoughts on this? > Sounds like a good plan to me when you need to maintain order to the queued commands. If a threadpool wasn't available, you would just end up writing a Queue and a single thread that sits on it, and putting work into the queue. It just happens that a threadpool handles that for you when set to one thread :-) > > On 26 March 2015 at 07:53, Marcus Ottosson <konstrukt...@gmail.com> wrote: > >> 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 >> > > > > -- > *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/CAFRtmOC5ZLX1SEGZtemO9EQPkM3g4uQ8jmwvKUMY7scwhpkhjg%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC5ZLX1SEGZtemO9EQPkM3g4uQ8jmwvKUMY7scwhpkhjg%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/CAPGFgA0p-GFkhc4e3FswSz0Mj%2BLq4DcWjdtJy-6BywNWyDVkDw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
