i don't know why i can't download it?
could u mail this docment to me !
thanks :)
my e-mail is
[EMAIL PROTECTED]
On 11月6日, 上午11时44分, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I do not have any problem to open the document. Could you please try
> again? Thanks.
>
> On Nov 5, 6:43 am, bzero
It sounds like we need some data based on tests that resemble typical Chrome
IPC traffic to help inform our decision here.
-Darin
On Wed, Nov 5, 2008 at 7:32 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]>wrote:
>
> Based on my implementation of Gears IPC on MacOSX, I found out that
> the perf of FIF
Dimitri wrote:
> The Win merge is now building and even passing some tests. Can
> Mac/Linux folks chip in and help out getting their bots green?
>
> And by "help out", I mean actually doing it, cuz I ain't no Mac or
> Linux expert :)
I've got four changes that do the complete merge on the Mac:
h
I do not have any problem to open the document. Could you please try
again? Thanks.
On Nov 5, 6:43 am, bzero <[EMAIL PROTECTED]> wrote:
> why i can't download the doc???
>
> On 10月29日, 上午8时55分, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > Hi all,
>
> > Here is a draft of a design doc forB
Based on my implementation of Gears IPC on MacOSX, I found out that
the perf of FIFO implementation is not as good as the one using Mach
port, especially for big message. For example, Gears IPC unitest
takes around 60 seconds to finish in a Tiger machine, compared with
around 10 seconds by using
On Wed, Nov 5, 2008 at 5:26 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:
> Sorry to be so persistent, but I don't understand why you need those things.
> Can you provide some specific examples?
> As far as I know, we need the ability to have shared memory. It seems like
> we can do that with mmap
Sorry to be so persistent, but I don't understand why you need those things.
Can you provide some specific examples?
As far as I know, we need the ability to have shared memory. It seems like
we can do that with mmap. We need a way to have shared waitable events
(like windows event objects), and
I've just edited the document to address Carlos' remarks about not letting
arbitrary client processes connect to a server process.
The relevant changes are:
* Using an authentication token for the Hello message.
* passing the token and channel_id in an env variable rather than on the
command line.
The main issue on OS X is that we can send Mach primitives back and forth
over a Mach port (shared mem. regions, semaphores, etc...) which is
something we'll nearly certainly need in the code. If we were to use a pipe
for IPC::Channel, we'd still need a Mach port for other stuff.
We need cross-pr
What do we need Mach semaphores for? You mention issues with named pipes,
but what about anonymous pipes? I'm curious why we need a different
implementation on OSX and Linux. It seems worth while if we can have a
shared implementation that meets all of our requirements.
What are the requirement
FYI: the rough plan is for a webkit merge to start every Tuesday. Dimitry
and I will team up with someone from the V8 team to make this a regular
event. This regularity should help keep the cost of the merges down and
allow everyone to be able to anticipate when changes made upstream to webkit
wi
Replying to a previous comment by jam:
> I'm not familiar with OS X so I can't comment on which specific
> implementation to use. However I'm wondering if it's possible to code
> proof of concepts of each method and time the latency? This will
> matter even more if plugins are planned to be run
Hi,
You can find the design document for OS X IPC at:
http://sites.google.com/a/chromium.org/dev/developers/design-documents/os-x-interprocess-communication
This document is a work in progress, feedback and comments are
welcome.
Best regards,
Jeremy
--~--~-~--~~~---~
Unbelievable ... chromium-dev just ate it.
:DG<
-- Forwarded message --
From: Dimitri Glazkov <[EMAIL PROTECTED]>
Date: Tue, Nov 4, 2008 at 4:02 PM
Subject: Re: [chromium-dev] started next webkit merge (to r38097)
To: chromium-dev@googlegroups.com
The Win merge is now building
Hi, I'd like to add couple of bits, perhaps it'll help to explain it from
another angle:
> > 2. "When there is any background task running and all Chrome windows are
>>
> > closed, Chrome will put up a systray icon to indicate that there are some
>> > number of background tasks being running. W
why i can't download the doc???
On 10月29日, 上午8时55分, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Here is a draft of a design doc for Background Browser Task:
>
> http://docs.google.com/View?docid=dd6rm2wb_3fmz8pnnp
>
> Your feedback is appreciated.
>
> Thanks,
>
> Jian
--~--~-
16 matches
Mail list logo
