Keep Channel#close thread-safety

[firejox]

If one thread is closing the channel and the other thread is sending data to channel, then both
threads may access the content simultaneously. It will be a bug under multi-thread environment.

[wooster0]

Shouldn't the multi-threading flag preview_mt be used here?

[firejox]

@r00ster91 The spinlock has internally use the preview_mt flag. The lock and unlock operations will be no-op if the program is compiled without the flag. Hence, I think there is no need to use preview_mt here.

[bcardiff]

@firejox what is the use case that makes you deal with closed channels?

If possible keep the history of this PR with some experiments (or even specs) that is pushing you to iterate on the solution.

Thanks!

[firejox]

@bcardiff Sorry, I just trace the channel.cr and find there is no lock protection on Channel#close. I will rollback the change because the new change is less related to this race bug.

[bcardiff]

I thought you've found further issues and I was intrigued by a code to stress it.

[firejox]

The new change is for the situation that some channel is closed before the Channel.select cleaning up the context. And this is another issue.