Mark newSingle/FixedThreadPoolContext as obsolete, document the reason

[elizarov]

• The will be replaced by another mechanism in the future. See Sliceable dispatchers: Provide alternative to newSingle/FixedThreadPoolContext via a shared pool of threads  #261 for details.
• The proposed replacement is to use the standard java API: Executors.newSingleThreadExecutor/newFixedThreadPool and convert to dispatcher via asCoroutineDispatcher() extension.

[Dico200]

I do not think that singleThreadContext should be deprecated and phased out. I think its functionality should remain a part of the API.

This is because limiting concurrent invocation of some set of methods/code to 1, is not the same as limiting it to one specific thread. Somewhere, you or someone else mentioned that it would break code if it uses ThreadLocal, however, I would hope that use case is not very common, as that should be unnecessary when there's just one thread already.

The problem I see is with regular mutable fields/properties not updating immediately on other threads unless they are volatile. The limitedThreadContext does permit access from various threads, even if it's only one at the same time. If the thread changes, field reads from the new thread might be outdated.

While the replacements you suggest are appropriate, I think there should be an option within the API that does the same as the current newSingleThreadContext. Whether that's by keeping it as is or creating an alternative, doesn't matter for this argument.

P.S. A test checking for this issue might be appropriate.

[elizarov]

@Dico200 Have you checked out issue #261? It explain the solution to the same problem (limiting # of threads), but without actually creating a separate thread pool (that would need to be disposed of) for that.

[Dico200]

@elizarov Yes, what I said was in light of the change proposed in #261.

I checked it again and I noticed I skimmed past these words a bit too quickly:

... some code in the wild that assumed that everything working in newSingleThreadContext was indeed happening in the single instance of Thread...

I missed the part with "in the single instance of Thread", which is the use case I describe.

However, I don't see anyone suggesting that it should stay for the reason I specified.

[qwwdfsad]

Let's move the discussion to #261.
I will merge this PR as it doesn't break anything and will not be removed in 1.0.0.