Re: Even more DO problems
Re: Even more DO problems
- Subject: Re: Even more DO problems
- From: publiclook <email@hidden>
- Date: Tue, 10 Jun 2003 22:03:19 -0400
On Tuesday, June 10, 2003, at 11:47 AM, Sailor Quasar wrote:
On Tuesday, June 10, 2003, at 06:38 AM, Joji Mori wrote:
Hey, one thing I'm pretty sure you have to make sure you aren't doing
is autoreleasing the client connection, if I remember correctly, the
connection has to remain until the end of the proxy object. What are
you using to create the NSConnection on the client side?
In regards to your responses... Yeah, I think you might know a bit
more about DO than me anyway
Dealing with retain counts has caused me a significant amount of
confusing crashes and code tinkering. I use NSDictionary to pass data
between threads, which causes stray retains everywhere, I have to
account for the retains NSConnection takes on the delegate and root
object, the retains the local objects are doing on the proxies... I'm
sure it's very simple to someone experienced,
The reference counting was add to the frameworks largely to support
distributed objects!
but I come from a paradigm where you're always paranoid about
disposing objects because you don't know what has a grip on it... I
also got a lot of autorelease confusion over whether NSNumber's
What confusion ? Did you obtain the object with a method with the word
alloc in it ? Did you call retain ? Then why on earth would you
release or autorelease the object ? It is that simple!
+numberWithWhatever methods autorelease the objects they return. It's
always nice to crash in
It may not be autoreleased but it is non of your concern because
+numberWithWhatever does not include the word alloc!
NSAutoreleasePool's release, with no indication of what the heck
object its crashing because was already disposed. I've found gdb's
call command invaluable here =). call (unsigned)[(id)[self
You can type > po [someObject retainCount] in gdb
You can type just > po someObject
You can enable zombies... This makes it easy to find which objects are
being re-released frm an autorelease pool. See NSDebug.h
ivar] retainCount] gets a bit annoying though... anyway, this appears
to work except for the fact that calling NSConnection's invalidate and
release methods on the parent NSConnection doesn't appear to
invalidate a proxy held by the remote client, even though invalidate
is specifically documented as doing so. And the continuing problem
that I can't get the message to get anywhere without the oneway
modifier...
Buy "Cocoa Programming" It includes a simple DO example. The oneway
keyword is not required and you seem to be making everything way too
difficult.
Sailor Quasar said...
I don't set up the send port for the server. I only set up a receive
port and rely on the documented semantics of NSConnection for it to
set
up the send port for the well-known server connection. The child
conections are supposed to use the same port semantics, as I
understand
it.
I pass it as (bycopy NSData *). Sorry, forgot to mention that before.
I
specifically don't want the data object proxied.
I already use an NSConnection delegate, but I didn't know that that
method could be used. How would it help, frankly?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
-- Sailor Quasar, guardian of Leraz's memory
"Face of stone, mind of calm, soul of love."
Email: email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.