On Mon, Nov 17, 2008 at 12:25 AM, John Abd-El-Malek [EMAIL PROTECTED] wrote:
I'm not trying to argue for one system or another, but I think things
like sending 1MB or 7MB of data quickly, or up to 256MB, aren't
actually needed by the existing code.
That's my suspicion as well, but the code is
On Mon, Nov 17, 2008 at 8:59 AM, Amanda Walker [EMAIL PROTECTED] wrote:
I'll sync up my windows build today and start collecting some stats on
both message sizes and latency that we can use as a concrete reference
point.
I should say we here--Jeremy may already be a step ahead of me here :-).
Not to beat a dead horse, but looking at these tables, it seems that
the decision to go one way or another can be made simply by looking at
the 3 bottom rows. However, I'm pretty sure you won't find any
existing messages that go over a few KBs. For any large data
transfer, we use shared memory
To my knowledge, we don't have specific speed requirements, so no,
there's no simple test that could show whether or not a given
mechanism is fast enough. However, as I noted yesterday, it should
be fairly straightforward to extract some performance data from the
windows build, which would at
Right on...
We can definitely support custom implementations for each platform, and we
should do that if it significantly lowers barriers and helps us get to a
better product.
I think it was reasonable to talk about sharing code here between Linux and
OSX because this code, while small and
On Thu, Nov 13, 2008 at 12:46 PM, Darin Fisher [EMAIL PROTECTED] wrote:
Right on...
We can definitely support custom implementations for each platform, and we
should do that if it significantly lowers barriers and helps us get to a
better product.
I think it was reasonable to talk about
To add to the discussion (or to the confusion) we have a similar
situation of Windows. Pipes are not the fastest IPC on windows. LPC
ports and in Vista ALPC ports are the fastest, then probably any
homebrew shared memory scheme and then pipes. The issues are that LPC
have a non officially
They work fine, though using Apache as an example, a Linux box running
Apache can generally handle a higher load than Mac OS X running on the same
hardware (historically, this has been true for any BSD-based kernel, not
just Mac OS X). That said, on modern hardware Apache is mostly limited by
TCP
If you want to argue using data, we'll use that. If you want to argue
using opinions, we'll use mine.
Linus
On Fri, Nov 7, 2008 at 7:55 PM, Amanda Walker [EMAIL PROTECTED] wrote:
They work fine, though using Apache as an example, a Linux box running
Apache can generally handle a higher load
Re-forwarding yet again...
-- Forwarded message --
From: Amanda Walker [EMAIL PROTECTED]
Date: Wed, Nov 5, 2008 at 10:22 PM
Subject: Re: [chromium-dev] Re: OS X IPC Design doc
To: chromium-dev@googlegroups.com
On Wed, Nov 5, 2008 at 10:11 PM, Amanda Walker [EMAIL PROTECTED
And one more from last night that got dropped:
-- Forwarded message --
From: Amanda Walker [EMAIL PROTECTED]
Date: Wed, Nov 5, 2008 at 10:42 PM
Subject: Re: [chromium-dev] Re: OS X IPC Design doc
To: chromium-dev@googlegroups.com
On Wed, Nov 5, 2008 at 10:32 PM, [EMAIL PROTECTED
--
From: Amanda Walker [EMAIL PROTECTED]
Date: Wed, Nov 5, 2008 at 10:07 PM
Subject: Re: [chromium-dev] Re: OS X IPC Design doc
To: chromium-dev@googlegroups.com
Since I'm the one who suggested mach IPC to jeremy, I should chime in here.
When we looked at the Windows IPC code (the set
On Thu, Nov 6, 2008 at 2:05 PM, Amanda Walker [EMAIL PROTECTED] wrote:
On Thu, Nov 6, 2008 at 4:45 PM, Darin Fisher [EMAIL PROTECTED] wrote:
It sounds like things are still fairly speculative...
Well, performance differences are not speculative, though we don't know
what the effect on
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 out
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
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),
16 matches
Mail list logo
