@mrobinson I couldn't move it to base because base and servo_config would create a circular dependency.
How about rename to runtime or move to profile?

@mrobinson I couldn't move it to base because base and servo_config would create a circular dependency. How about rename to runtime or move to profile?

Please move fn channel() to the WebGL crate in this case. Even though there is a generic channel implementation it isn't always just the multiprocess option that might be controlling whether or not we want an IPC channel or a crossbeam channel.

Please move fn channel() to the WebGL crate in this case. Even though there is a generic channel implementation it isn't always just the multiprocess option that might be controlling whether or not we want an IPC channel or a crossbeam channel.

Ah I think I can add a parameter to check instead. So we can still have a create channel function in this module.

In addition, please use this new data structure to replace OpaqueSender in components/shared/profile/mem.rs.

Do you mean type alias OpaqueSender to GenericSender? Because ``OpaqueSender` seems to be a trait. There are other places will need to update I think.

Do you mean type alias OpaqueSender to GenericSender? Because ``OpaqueSender` seems to be a trait. There are other places will need to update I think.

Since OpaqueSender is solving the same sort of problem, I think you could modify the code that was using it to use GenericSender instead.

Since OpaqueSender is solving the same sort of problem, I think you could modify the code that was using it to use GenericSender instead.

After looking into it further, I found there are more types passed in profile's run_with_memory_reporting function. Some types are more than just a sender field. I think we still need to keep OpaqueSender for these types.