SharedChan is not Freeze

[metajack]

The recent rewrite of std::comm had one major side effect not mentioned in the notes. SharedChan is no longer Freeze. This breaks a lot of code in Servo.

cc @alexcrichton

[metajack]

Ok, That was a bit of an overreaction. So far this broke the Font structure which had a SharedChan to send profile data to the profiler task. This turned out to be unused, but I expect I will run into elsewhere too, and it's not so easily removed unless we want to redo the profiler.

[thestinger]

I don't think there's much use for a Freeze bound in most cases. For example, an Arc needs to make sure that the contained object can be shared between threads without extra synchronization, and using Freeze is overly strict. It would be nice to replace it with another kind more targeted at thread-safety.

[metajack]

In this case I was trying to use it with RefCell. The other uses of the profiler SharedChan may not be in RefCells and may not run into this. I'm still not done with the port, so I will update if I find more problems.

[alexcrichton]

Hm, as I think about this, this may be a good thing. Chan should definitely not be Freeze, and although an instance of SharedChan is in theory Freeze, sharing should be achieved by cloning instead of through an arc, so this may be working-as-intended?

[metajack]

Apparently it is also not Send.

[alexcrichton]

I'm going to think of this closed as working-as-intended but instead flag this as needstest for now.

All of Port Chan and SharedChan cannot be Freeze in the sense that they can have shareable read-only copies among tasks. It's my understanding that this is what Freeze means today for at least MutexArc.