Using BufferedReader and InputStreamReader with virtual threads

[Karsten Pagel]

Well, since i'm just experimenting, it would be exaggerated to say, that 
i'm running into issue ;-)

i stumbled over it, when creating a simple testcase to check out, how to 
use virtual threads and to do some first steps...
i have a fixed-size executorservice with one single worker-thread used
as carrier-executer and started two virtual-threads - each opening a 
tcp-connection to a simple chatserver. i used the buffered reader for 
simplicity (each virtual thread should print complete textlines send to 
them, thats why is used BufferedReader.readLine()).
Since it didn't do what i expected to do (only one of them printing out 
messages), i started to dig deeper... it works fine when using the 
inputstream directly.
i think, there may be many third-party-libs using bufferedreader (for 
example reading csv-files row by row) or inputstreamreaders for 
charset-conversation - thats why i'm asking.

I took a look at the (Buffered)Reader-class and your right. Since the 
lock-object is visible to subclasses it's impossible to replace it with 
a ReentrentLock without breaking compatibility with other classes...

since the default lock-object is 'this' it is sadly not possible to 
implement a dirty workaround, cause the reader-instance could be used
as lock-monitor almost every (it's not enough, to synchronize internally)...

Maybe someone has a better idea?

-Karsten

PS: i didn't run with -Djdk.tracePinnedThreads=full ; Thanks for that 
hint. I launched my testcase in debug-mode, manually suspending the 
carrier-thread to find out, what's going on...
My testcase was specially designed to run two virtual-threads on one 
'real'-thread to see with my own eyes, how multiple data is processed on 
one physical carrier thread. what an amazing feature! :-)


Am 10.08.2020 um 17:17 schrieb Alan Bateman:
> The approach that we've been using is to separate direct uses of these
> APIs from cases that extend the java.io classes. So if you use a
> BufferedInputStream or BufferedOutputStream directly then they will use
> j.u.concurrent locks and blocking in read/write won't pin the carrier
> thread. If you extend these classes then you are out of luck because the
> sub-class may assume all methods are synchronized. OutptuStreamWriter
> (and the underlying sun.nio.cs.StreamDecoder) and PrintStream are other
> examples that do the same. I thought we had changed InputStreamReader
> (and sun.nio.cs.StreamEncoder) but it seems not - this may be an
> oversight so I'll look into that.
>
> So are you running into issue? Are running with
> -Djdk.tracePinnedThreads=full to find these issues?
>
> -Alan
>