An old email thread with relevant info:
--------
From: Aaron Boodman
On a background thread (pun intended) I have been [pondering the]
1-to-1 structure for worker threads and windows.
Basically, whenever the UI needs to communicate with [sync code], or
[sync code] needs to tell the UI something, we have a problem.
<snip>
Has anyone on the C++ side given much thought to this? From my point
of view, as a developer, it shouldn't be much different than our
current thread design, except that you should be able to name threads,
speak directly to them, or broadcast to all threads.
--------
From: Erik Arvidsson
Let me see if I understand you correctly.
Are you suggesting that it would be good to let multiple instances of
the same application share the same sync thread and then let that sync
thread broadcast changes so that all applications can update their UI.
That seems like a nice idea and it would bring us closer to a UI less
sync background thread.
--------
From: Aaron Boodman
Yeah, sorry I wasn't clear.
I think that conceptually, [you have] a "sync process". The sync
process would be started by the first [app] window. All
[app] windows could communicate with the sync process (so
implementation-wise, it should probably live outside the window), and
the sync process could broadcast notifications to all windows.
It would be nice, but not required, if the sync process were an OS
process, so it could be isolated from the browser in terms of memory.
Also, in the future, it would be nice if the sync process could be
kicked off on OS login (with user approval of course).
--------
From: Chris Prince
Sounds like a good idea. Let's setup a PostLaunchIdeas wiki page
so we don't forget about these.
Original issue reported on code.google.com by gears.te...@gmail.com on 28 Jun 2007 at 8:07
Original issue reported on code.google.com by
gears.te...@gmail.com
on 28 Jun 2007 at 8:07