Re: [Pyobjc-dev] autorelease pool page corrupted
Brought to you by:
ronaldoussoren
Menu
▾
▴
Re: [Pyobjc-dev] autorelease pool page corrupted
|
From: Jake W. <del...@gm...> - 2013-11-21 13:15:36
|
That's really good to know. Thanks. According to Diez's suggestion, I've already moved to PyQT, which is much better than wx! Every aspects of what I need work very well. On Thu, Nov 21, 2013 at 8:44 PM, Ronald Oussoren <ron...@ma...>wrote: > > On 21 Nov 2013, at 13:37, Jake Wang <del...@gm...> wrote: > > Thank you Ronald, > > I didn't use Objective-C before, and only in a recent project, I realised > that some functions were required to use some Objc code, then I found > PyObjc is a great option. Sorry for the stupid question I posted :) > > > It is not a stupid question at al! The answer is only obvious if you know > how memory management in Objective-C actually works, which is different > from Python’s and furthermore PyObjC tries hard to hide most of the memory > management from Python programmers but that abstraction layer cannot hide > everything (I wish it could…) > > Ronald > > > Anyway, with Diez's and your help, the issue I encountered was resolved, > and I learned it about the NSAutoreleasePool. > > Thanks again! > Jake > > > On Thu, Nov 21, 2013 at 7:34 PM, Ronald Oussoren <ron...@ma...>wrote: > >> >> On 03 Nov 2013, at 12:14, Diez B. Roggisch <de...@we...> wrote: >> >> Hi, >> >> the problem is obvious: you allocate the pool from within the *MAIN* >> thread, not within the run-method of your EventHandlingThread. Thus it's >> essentially useless. >> >> >> That’s obvious if you already know Objective-C :-). For the records >> (and something that I should somehow include in PyObjC’s documentation): an >> NSAutoreleasePool is a fairly magic object that has a global effect for a >> single thread. You must allocate a pool on every thread that uses Cocoa, >> and if you create two nested pools like so: >> >> p1 = NSAutoreleasePool.alloc().init() >> p2 = NSAutoreleasePool.alloc().init() >> >> Then draining (clearing) p1 will also drain p2. That is, >> NSAutoreleasePool objects can (more or less) be seen as markers in a >> per-thread stack of objects and draining a pool calls “release” on all >> objects on the stack upto that marker. >> >> For the most part you don’t have to worry about this, as long as you >> create an regularly drain an autorelease pool on every thread (and you >> don’t even have to do the draining bit if you use a Cocoa event loop in the >> thread) >> >> Ronald >> >> >> >> Diez >> >> On Oct 29, 2013, at 3:03 AM, Jake Wang <del...@gm...> wrote: >> >> Hi Diez, >> >> Thanks for your sample code, which is really helpful. >> >> Please find my sample code as attached. >> >> Entrance script: test_wx_and_event_2.py >> >> Thread 1 - the main thread >> Thread 2 - user_event.EventHandlingThread >> >> It is slightly different, because only the first thread (the main thread) >> has PyObjc code, the second thread just shares an event queue with the >> first thread. >> >> After I added auto release code in the second thread, I got a new error: >> >> objc[1488]: Object 0x10791bf50 of class __NSCFString autoreleased with no >> pool in place - just leaking - break on objc_autoreleaseNoPool() to debug >> >> Also got the system error when quitting the app. >> >> Thanks, >> Jake >> >> >> On Sun, Oct 27, 2013 at 2:45 PM, Diez B. Roggisch <de...@we...> wrote: >> >>> >>> >>> On Oct 27, 2013, at 3:35 AM, Jake Wang <del...@gm...> wrote: >>> >>> Hi Diez, >>> >>> Thanks for your reply and links, I tried some auto release code in the >>> sample code (https://github.com/jiakuan/wx-sample), but still no luck. >>> >>> >>> I don't see it, can you show it to me? >>> >>> >>> >>> I tried to replace the following code: >>> >>> def OnUnexpectedExit(event): >>> # >>> # Event handler that deals with the unexpected close event. >>> # >>> wx.GetApp().ExitMainLoop() >>> >>> to this: >>> >>> def OnUnexpectedExit(self, event): >>> # >>> # Event handler that deals with the unexpected close event. >>> # >>> sys.exit() >>> >>> Then no such error any more. I guess the issue was related to wxPython >>> with PyObjc in some way. >>> >>> >>> I'm not sure if that's a good solution. There are a *lot* of >>> possibilities here, and under normal circumstances, whatever you do in a >>> user-space program shouldn't cause problems for the OS. However, the rather >>> "rude" way of terminating a program you chose here might have just push the >>> problem from your logging output to the system log's output, because some >>> application cleanup hasn't been performed. This is just guessing, but a >>> check couldn't hurt. >>> >>> What you *must* verify though is that the lack of autorelease-pool >>> doesn't introduce garbage over time. >>> >>> I created the attached program to simulate that. You can ignore most of >>> it of course, but if you put a call to "garbage_producer" with e.g. a >>> million bytes as argument into your event handler, you should be able to >>> see in the activity monitor if the process grows in size. >>> >>> If so, you have to use a pool. >>> >>> >>> >>> The reason why we choose PyObjc and wxPython is that we want to use >>> Python language to share the majority of business logic on both Mac OS X >>> and Windows. The platform-dependent requirement is a relative small part, >>> which only contains global events listening, and a system tray icon (this >>> code can be shared on both Mac and Windows too). >>> >>> Any better solutions? >>> >>> >>> Better is relative. I personally would *never* go with wx, as it's not >>> good in looks as well as API. If being cross-platform was justified for me >>> enough (meaning the UI was sophisticated enough so that developing it >>> natively would be a major effort), I'd be using Qt, and one of it's >>> available bindings. >>> >>> Of course, these are matters of taste. I just suggest exploring the >>> alternatives. >>> >>> Diez >>> >>> >> <wx-sample.zip> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform >> that >> developers love is also attractive to malware creators. Download this >> white >> paper to learn more about secure code signing practices that can help keep >> Android apps secure. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk_______________________________________________ >> Pyobjc-dev mailing list >> Pyo...@li... >> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >> >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform >> that >> developers love is also attractive to malware creators. Download this >> white >> paper to learn more about secure code signing practices that can help keep >> Android apps secure. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk_______________________________________________ >> Pyobjc-dev mailing list >> Pyo...@li... >> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >> >> >> > > |
