On May 5, 10:44 am, Scott Hess wrote:
> I agree with the earlier argument about not larding startup with
> things like writing new files to id the coming-up Chrome to
> late-coming instances. An alternative might be to acquire a lock to
> protect the profile, and write an id asynchronously aft
I agree with the earlier argument about not larding startup with
things like writing new files to id the coming-up Chrome to
late-coming instances. An alternative might be to acquire a lock to
protect the profile, and write an id asynchronously after startup.
The late-coming instance would see th
Thanks for elaborating.
So if we look at it another way, there are several different problems
that ProcessSingleton is currently used to solve:
- Prevent multiple instances of Chromium from referring to the same
profile/user data directory. In the general sense, what we need here
is a way to ac
I'm sorry for the late response, I've been quite busy last week.
2009/4/27 Amanda Walker :
> "Hacky" is fairly subjective: are there particular things about the
> existing implementation that bother you? Currently they are different
> for each OS because each OS has its own issues surrounding la
On Mon, Apr 27, 2009 at 8:21 AM, Evan Martin wrote:
>
> On Thu, Apr 23, 2009 at 1:35 PM, Nikita Ofitserov wrote:
>> Don't try to get pid dynamically, but create on startup in datadir
>> file 'ChromePid' or something like that with pid. Also, create an IPC
>> channel with channel_id equal to pid
On Mon, Apr 27, 2009 at 8:05 AM, Mike Pinkerton wrote:
>
> On Sun, Apr 26, 2009 at 5:50 PM, Amanda Walker wrote:
>> Application startup is one of the areas where we count every
>> millisecond, and try to touch the disk as little as possible. I don't
>> think it's safe to assume that the cost of
On Mon, Apr 27, 2009 at 11:21 AM, Evan Martin wrote:
> That leaves process_util for Linux and Mac, which uses fuser (or
> something similar) and that is a hack. However, it's only used for ui
> tests, I believe -- it's not needed in normal usage.
The Mac uses ps -xw, but the same reasoning app
On Thu, Apr 23, 2009 at 1:35 PM, Nikita Ofitserov wrote:
> Don't try to get pid dynamically, but create on startup in datadir
> file 'ChromePid' or something like that with pid. Also, create an IPC
> channel with channel_id equal to pid with forced FIFO mode on POSIX.
> Current POSIX implementati
Many of those are done lazily specifically so that they won't slow
down app launch. However, I didn't mean to come across as "jumping
all over" the idea--I was just saying we shouldn't brush it off as
insignificant without measuring it.
--Amanda
On Mon, Apr 27, 2009 at 11:05 AM, Mike Pinkerton
On Sun, Apr 26, 2009 at 5:50 PM, Amanda Walker wrote:
> Application startup is one of the areas where we count every
> millisecond, and try to touch the disk as little as possible. I don't
> think it's safe to assume that the cost of creating and writing to a
> file is negligible in this context
On Thu, Apr 23, 2009 at 4:35 PM, Nikita Ofitserov wrote:
> Currently there are different implementations of ProcessSingleton and
> ChromeBrowserProcessId() on Windows, Linux and Mac. Most of them are
> quite hacky, so there should be a better way. I think current IPC
> system with slight modifica
2009/4/25 Nikita Ofitserov :
> We need to create this file only once, during main process startup,
> not for every renderer/plugin process. Sorry if I haven't made it
> clear. I don't think that creating a text file once with one number
> would slow startup too much.
Application startup is one of
What if a user starts chrome twice in quick succession? Process A
starts, looks for the pid file. Next process B starts and does the
same. Both don't see a file, so they both create one. One overwrites
the file created by the other. Now there are two "main" processes,
only one of which can be foun
On 25 апр, 05:09, Peter Kasting wrote:
> On Thu, Apr 23, 2009 at 1:35 PM, Nikita Ofitserov wrote:
> > I suggest:
> > Don't try to get pid dynamically, but create on startup in datadir
> > file 'ChromePid' or something like that with pid.
>
> Creating files during startup would slow startup too m
On Thu, Apr 23, 2009 at 1:35 PM, Nikita Ofitserov wrote:
> I suggest:
> Don't try to get pid dynamically, but create on startup in datadir
> file 'ChromePid' or something like that with pid.
Creating files during startup would slow startup too much. Chrome crashing
would leave a stale PID file
15 matches
Mail list logo
