Very interesting!
> As a result, this shouldn't impose any additional requirements or
drastically alter our IPC designs.
I'd actually be surprised if this didn't have a bearing on our IPC choice.
Afterall, the Windows IPC deals in DuplicateHandle, which is all about
exposing new resources to the
Here's a rough-cut starting point for the sandboxing on OS X. Brief,
yes, but with only 1 API point that does pretty much everything we
need with few obvious restrictions, I'm not sure what more to say...
Feedback welcome.
http://sites.google.com/a/chromium.org/dev/developers/design-documents/sa
On Mon, Nov 10, 2008 at 1:31 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> If you this benchmark you need to be careful to do a fairly complete
> impl of both, we want to make sure we account the overhead that
> involves variable size (up to 256M on windows) packets, the duplex
> nature and w
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 sanction
hello chromiumAny good info of linux version chromium! Can you
notice status for a while(one week,or one monty),I want to replace firefox
with chrome.
thanks!
ifone
2008/11/11
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
Hi Zypher,
I'm sorry to hear it's not working properly for you. If you could copy+paste
the error and/or attach your config.cmd file, it would be easier for me to
help you. I bet I can fix the issue for you rather than you having to work
around it. Either way, I don't think the problem is with md5
