On Dec 2, 2007 5:46 PM, Adam R. Maxwell <[EMAIL PROTECTED]> wrote:
>
> On Dec 2, 2007, at 8:12 AM, Christiaan Hofman wrote:
>
> >
> > On 2 Dec 2007, at 4:48 PM, Adam R. Maxwell wrote:
> >
> >>
> >> On Dec 2, 2007, at 5:25 AM, Christiaan Hofman wrote:
> >>
> >>> Another question. Should we actually make the connection multi
> >>> threaded? I think it's wrong. It's only accessed from a singl
> >>> thread.
> >>
> >> Check the comment in -init and that blog post linked. It's necessary
> >> because we use the same ports on the other end. Removing it leads to
> >> exceptions.
> >>
> >
> > Really? I understand this differently. Note they're still different
> > connections. The post (and the docs) says that you gat the same
> > connection if you use the same ports *in the same order* for the
> > connection, in the case of the post when you use multiple clients
> > with the same ports.
>
> Yeah, Tsai's setup seems odd, and he's quoting a different section of
> the docs. That was just a reminder of the problem. The part I quote
> in -init says:
> "If an NSConnection object exists that uses the same ports, but
> switched in role, then the new NSConnection object communicates with
> it. Messages sent to a proxy held by either connection are forwarded
> through the other NSConnection object. This rule applies both within
> and across address spaces."
>
> I interpret this to mean that if the ports are reversed on the other
> end, you end up communicating through the original connection. It's
> not clear what the implications are; the DO documentation is not good,
> as far as I'm concerned. I filed a radar months ago asking for
> clarification on -enableMultipleThreads and a separate one asking for
> docs on deallocating an NSConnection.
>
>
AIACT it means that it creates a new connection (unless one already exists)
and connects it to the one with the reversed ports. So they're different
NSConnection objects. So each one can work on a different thread, neither
needs to be multithreaded. It's just that when you create several client
connections with the reversed ports (as Tsai seems to do) , they all return
the same connection. So you still end up with just 2 connections. But now
the (single) clients might work on several threads, so it needs to be
multithreaded. However this setup seems wrong from the start. But in this
case the server still does not need to be multithreaded.
>
> > Also removing it does not give me an exception.
>
> Ah, but the exception doesn't occur all the time (or it may only occur
> on dual proc systems...I forget). For even more fun, multiple threads
> are enabled by default on 10.5, but disabled by default on 10.4.
>
I find that strange, I think connections are best used from a single
thread.
>
> I originally added enableMultipleThreads because I hit that exception
> during development. Since I forgot to comment it, I removed it last
> May since it seemed unnecessary (using a similar argument to yours),
> tested it, and it worked fine. We then released a new version and got
> a couple of exception reports (I was able to reproduce it).
>
That may have been a side effect of the bug we had a while ago where the
connection was accessed from the wrong thread. I'm quite sure our
connections don't need to be multi treaded. In fact, when that exception
occurs it's probably a sign of a bug in our code which we should fix rather
than ignore by allowing multiple threads to access the connection.
>
>
> >>> On 2 Dec 2007, at 2:05 PM, Christiaan Hofman wrote:
> >>>
> >>>> Sorry, I see you already removed oneway from setLocalServer:.
> >>
> >> Yes, for precisely that reason. It's fast anyway, since we're
> >> dealing
> >> with NSMachPort.
> >>
> >> --
> >> adam
> >
> > Right.
> >
> > BTW, couldn't we just use [mainThreadConnection rootProxy] for the
> > serverOnServerThread? It's the same object.
>
> I don't know. I'm pretty disinclined to mess with it now, since I
> know it's working on Tiger and Leopard.
>
That's a good point.
Christiaan
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
