Another question. Should we actually make the connection multi
threaded? I think it's wrong. It's only accessed from a singl thread.
Christiaan
On 2 Dec 2007, at 2:05 PM, Christiaan Hofman wrote:
Sorry, I see you already removed oneway from setLocalServer:.
Christiaan
On Dec 2, 2007 2:04 PM, Christiaan Hofman <[EMAIL PROTECTED]> wrote:
BTW, can we be sure that the serverOnServerThread has been set after
initBlocking has finished? My problem is that the serverDidSetup flag
is set from the server thread after calling setLocalServer:, but this
method is oneway void. So shouldn't this be just void, or otherwise
shouldn't the serverDidSetup flag be set in setLocalServer:?
Christiaan
On 2 Dec 2007, at 1:54 AM, Adam R. Maxwell wrote:
>
> On Dec 1, 2007, at 4:41 PM, Christiaan Hofman wrote:
>
>> On 2 Dec 2007, at 1:28 AM, Adam R. Maxwell wrote:
>>
>>> If I compile and run the following code, the ivars in the
parent and
>>> child classes are released.
>>>
>>> For some reason I was thinking that the subclass' dealloc
>>> wouldn't be
>>> called. Since it is called, we don't have to do anything if super
>>> returns nil...right? I'm fully confused now.
>>>
>>
>> That's correct. In -[Parent init] (called from within -[Child
>> init]) , the object is released. Therefore it's -dealloc is called.
>> As the object is a Child, this is -[Child dealloc]. So _string is
>> released. And it also calls [super dealloc], so also _parentName is
>> released. So there never has to be an explicit release of ivars in
>> init, cleanup is all taken care of by dealloc (as it should).
>
> Right. So we can get rid of that release-in-init madness and not
> worry about freeing anything twice.
>
> I think I started out with this idea that the if(self=[super init])
> check was there to avoid leaking ivars, and never bothered to
think it
> through. I guess if you're going to fire off threads or do
something
> expensive it's worthwhile to see if super's init failed, but
otherwise
> it doesn't do much.
>
>> Anyway, in practice for us this would never occur, as -[NSObject
>> init] is empty and never returns nil.
>
> Unless NSAllocateObject() (and presumably malloc) fails, but by then
> you're SOL anyway.
>
> --
> adam
>
>>
>
>
----------------------------------------------------------------------
> ---
> SF.Net email is sponsored by: The Future of Linux Business White
Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Bibdesk-develop mailing list
> Bibdesk-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
