TextEncoding iconv instances are shared between threads
The icon_t pointers returned from iconv_open should only be while processing a single text stream, because in general they may contain some state about the text being processed.
However, we currently don't take any measures to prevent this from happening, as GHC.IO.Encoding.Iconv.mkTextEncoding shares one pointer amongst all use sites of that TextEncoding in future -- even if those uses occur on different threads!
This could lead to arbitrarily strange heisenbugs depending on the iconv implementation.
Either we should:
- Make it clear that the user should recreate a TextEncoding anew for every use site
- (Better), elaborate the TextEncoding interface so that we can call iconv_open/iconv_close at the start and end of processing a particular text block, and ensure that the token doesn't escape so it can be accessed from multiple threads simultaneously