Re: [dev-servo] Using IPC channels with Tokio?
Yes. Of course. On Wed, Nov 16, 2016 at 8:16 AM, Eddy Bruel wrote: > For the Servo debugger, now that we've begun landing the Rust interface to > the Debugger API, we can also started working on the next step, which is an > IPC client/server on top of that Rust interface. This IPC server will allow > the main debugger server, which lives in a separate process, to talk to the > debugger API of one or more script threads. > > Since the IPC client/server inherently asynchronous in nature, I was hoping > to implement the client side API with futures. Essentially, for each > synchronous function on the server side, there will be a corresponding > asynchronous function on the client side that returns a future. > > The futures on the client side will typically be resolved when we receive a > message from an IPC channel (which will typically be either a reply to a > pending request, or some kind of notification). For that to work, we need > to be able to hook IPC channels into a Tokio event loop. > > Given the above, I wondered if there is currently any support for using IPC > channels with Tokio? And if not, would it be possible to implement this? > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Using IPC channels with Tokio?
Thanks On Sun, Dec 4, 2016 at 10:51 AM, Olaf Buddenhagen wrote: > Hi, > > On Wed, Nov 16, 2016 at 07:48:36PM +0100, Eddy Bruel wrote: > > > To make IPC channels usable with Tokio, we'd have to take whatever low > > level IO primitive IPC channels use under the hood, and then reimplement > > the same logic that the existing IPC channels implement on top of this, > but > > using a streams based API (by streams, I mean the streams from the > > futures-rs, crate). > > > > I'm not quite sure how much work this would be, since I don't know how > > complex ipc channels are under the hood. > > The low-level I/O in some of the platform back-ends in ipc-channel is > quite intricate -- and might change in incompatible ways at any time. I > don't think it's a good idea to try reimplementing it. Rather, we should > try to reuse as much of the existing low-level code as we can, while > creating an alternative API entry point. > > My *intuition* is that this should be quite doable -- though of course I > might be wrong... Especially since I'm not really familiar with Tokio > yet, beyond having some very rough idea of what it does. > > -antrik- > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] custom derive for Deref/DerefMut
Unsubscribe On Jul 13, 2017 8:20 PM, "Bobby Holley" wrote: Sorry, wrong link. I meant: https://reviewboard.mozilla.org/r/157064/diff/3#index_header On Thu, Jul 13, 2017 at 5:13 PM, Bobby Holley wrote: > There's a lot of boilerplate involved just to make a newtype [1]. Is this > something we could add a custom derive for? > > [1] https://treeherder.mozilla.org/#/jobs?repo=try&revision= > 9adf7a220ac8fa870f30a25a1ff8c71da65873fa > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] New Servo WebGL Architecture Proposal (benchmarks included!)
Unsubscribe me On Jul 21, 2017 4:58 PM, "Imanol Fernández" wrote: Hello, I want to share the ideas, code and some benchmarks of the new Servo WebGL architecture and refactor I'm working on. I'd love to hear some feedback about the big picture. For smaller things or nits we could do that in the PR review (which I'll plan to do beginning next week if there aren´t strong opinions about the overall architecture). First, I'll mention some of the problems of the current Servo/WebRender WebGL implementation and source code organization * Part of the WebGL implementation is included in WebRender. This makes very slow to make WebGL contributions. For example in order to add a new WebGL method I usually need push a PR to gleam (wait until it's merged and the crate published), then submit another PR to WebRender (wait for the review & merge) and wait again until the new WR is merged into Servo (with low control about it because WR can have in-progress non-related features not ready-to merge) * When adding WebGL related code to WR, the WebGL code is not tested when it lands into WR. It's only tested when a WR update lands into Servo. When a WebGL related test fails in a WR update it's usually fixed by reverting the commit that caused it to avoid delaying the WR update. This makes the testing process difficult. * The current implementation creates a new WebGL renderer thread (with it's ipc-channel) for each canvas created in JavaScript. This can quickly exhaust the file descriptor's available in the system for webpages that create a lot of canvases (e.g Shadertoy) or on games that require many canvases. Creating a canvas instance in JavaScript is slower than it should because of this too. * WebGL commands are currently run in the WR backend thread which could be bad for UI latency (see https://github.com/servo/webrender/issues/607) * Currently there are two ipc-channels steps for each WebGL-call to hit the driver (JS ==> WebGL Render Thread ==> WebRender). This adds a lot of overhead. * Slow compilation times: Modifying a WebGL command code recompiles WebRender_traits which causes additional component recompilations in Servo. * Flickering and shyncronization problems with the WR compositor (I created this issue some time ago: https://github.com/servo/servo/issues/14235) Goals that I want to achieve in the new WebGL architecture design: * Make WebGL development cycle easier. * Minimize the render path overhead for WebGL commands. * Flexible architecture for multiprocess and inprocess scenarios. * A special mode for packaging WebGL applications (not enabled by default, more details later) * Faster compilation times * Proper shyncronization to avoid flickering issues * Compatibility with the WebVR render path Now I'm going into some detail of how I tried to best achieve each stated goal. You can check the "almost ready for PR" source code here: https://github.com/MortimerGoro/servo/commit/c2db42bbbae6d6cb612d0aa2580552 a2ff3b0acf (still have to add more docs, do a rebase and clean some tests) Make WebGL development cycle easier. --- This is fixed by splitting the WebGL code into it's own component and removing all WebGL code from WebRender. Additional benefits for WebRender (see https://github.com/servo/webrender/issues/1353): * Simplify the internals of resource cache by removing the GL context management code. * Remove the WebGL cargo feature, since not all clients use it. I opted to move the WebGL code into a Servo component. It eases development, testability and I don't think that there are use cases to use the component outside Servo. Anyway, it's a low coupled component, so it will be easy to move if required but I don't think that it's worth it. The connection between a WebGL canvas and WR is implemented via the WR ExternalImage APIs as Glennw recommended. When the new Architecture Lands in servo, I'll make a separate PR to removes all the unneeded WebGL management code in WR. Minimize the render path overhead for WebGL commands -- The new architecture creates a single thread/process to manage all WebGL commands from multiple canvas sources. This will reduce the footprint for creating a new canvas (avoid creating specific thread + ipc-channel) and reduces the render-path for each WebGL command by using a single "channel step" Flexible architecture for multiprocess and inprocess scenarios -- One of the things I don't like about the current implementation is that it uses a IpcSender instance as the entry point to send the WebGL commands from the Script Thread to the renderer in many parts of the source code. IMO this is not very flexible because we may be interested in batching WebGLCommands, using shared memory, or other channel approaches to improve performance. A WebGL demo can ea
