Paul Sandoz <[EMAIL PROTECTED]> writes:
>
> >> I had to change the directory data source to
> >> use synchronous proxy observers just like the js
> >> LDAP data source so it can be really slow.
> >
> >I don't really understand why the JS datasource uses sync proxies
> >(peterv?). Given that this is really a callback, and there's no
> >interesting way to recover from an error in a callback, it seems
> >like async (fire & forget) would be fine. On the other hand, using
> >async proxies is probably more likely to subject us to event queue
> >flooding if there are a lot of entries (like bug 50104). Anyone, you
> >could conceivably try switching one or both of these proxies to being
> >async and see whether things get better or worse.
> >
>
> If you use async then the GUI becomes very sluggish
> in debug, not sure what its like in release, as per
> bug 50104.
>
> I am testing against an internal LDAP server which
> contains all Sun employee info, so it is very
> responsive.
OK, that makes sense. You might want to try apply danm's patch in
50104 with async proxies and see if it makes any difference. Either
way, if you could comment in the bug that'd be great... because we
really should apply pressure to get 50104 fixed, if at all possible.
> Also modified the ds so that non proxy RDF observers
> are used for synchronous address books.
> I do this by checking if the current thread
> is equal to the main thread (which is the
> UI thread):
>
> nsCOMPtr<nsIThread> currentThread;
> rv = nsIThread::GetCurrent (getter_AddRefs(currentThread));
> NS_ENSURE_SUCCESS (rv, rv);
> nsCOMPtr<nsIThread> uiThread;
> rv = nsIThread::GetMainThread (getter_AddRefs(uiThread));
> NS_ENSURE_SUCCESS (rv, rv);
>
> nsCOMPtr<nsISupportsArray> observers;
> if (currentThread == uiThread)
> {
> }
> else
> {
> }
>
> I presume this will be OK in the future.
> i.e. the ui thread will always be the main
> thread...
That seems pretty likely to me, though I'm not entirely sure how we could
verify that assumption. Maybe ask in .xpcom and/or .xpfe?
Dan
--
