Re: autorelease pool page corrupted

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 <[email protected]>wrote:

>
> On 21 Nov 2013, at 13:37, Jake Wang <[email protected]> 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 <[email protected]>wrote:
>
>>
>> On 03 Nov 2013, at 12:14, Diez B. Roggisch <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>>
>>>
>>>
>>> On Oct 27, 2013, at 3:35 AM, Jake Wang <[email protected]> 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
>> [email protected]
>> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>>
>>
>
>

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk

_______________________________________________
Pyobjc-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyobjc-dev