Comment #6 on issue 15891 by [email protected]: implement showModalDialog on mac & linux http://code.google.com/p/chromium/issues/detail?id=15891
argh, I had written a big reply but it got lost. My recollection was that we'd implement SyncChannel without the cross process events to unblock other work, then we'd revisit the issue later. Now that "later" is here, I think it's valuable to look for alternatives. However I can't think of any robust ones. The cross process event is used per tab, and is set when a modal dialog is shown. This allows all processes handling content for that tab (i.e. renderer & plugin processes) to run nested message loop. This matches what would happen if they were running in one process, and avoids deadlock. Trying to simulate this with other forms of IPC, such as our async messages, won't be as robust/correct. You can't just send messages when this occurs to all child processes, since new ones can be created later (say a plugin is created in the nested loop of the renderer). I agree we want to avoid using resources that hang around after a crash. I'm not saying we should switch WaitableEvent to this, but perhaps only the named version. I don't understand why it can't be cleaned up by Chrome on restart? Perhaps another alternative to doing this is to use the MWAIT & MONITOR instructions? I'm not sure if they're on other CPUs though. http://www.rz.uni- karlsruhe.de/rz/docs/VTune/reference/Guideline_for_MONITOR_MWAIT.htm -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings --~--~---------~--~----~------------~-------~--~----~ Automated mail from issue updates at http://crbug.com/ Subscription options: http://groups.google.com/group/chromium-bugs -~----------~----~----~----~------~----~------~--~---
