Question about blocking queues and continuations

[Oliver Plohmann]

> On 29/07/2020 09:04, oliver at objectscape.org wrote:
>> :
>>
>> Problem is now that the Java scheduler that schedules virtual threads in
>> Loom has no access to queueTwo as LinkedBlockingQueue is a class in the
>> class library. LinkedBlockingQueue is not a language built-in type as
>> channels in Go. So the Loom Java scheduler has no way to ask queueTwo
>> whether it is empty and therefore there is also no possibility to
>> withdraw the virtual thread from line 2 and assign it to some other
>> blocking channel as in Go.
> If a virtual thread blocks in LBQ::take then the virtual thread will 
> be parked and the underlying carrier thread will be released to do 
> other work. If someone else puts/offers an element into the queue then 
> it will unpark the blocked virtual thread, which just queues the 
> thread to the scheduler so it can continue execution. So conceptually 
> similar to goroutines but doesn't need to have support in the Java 
> language.

Good to hear. So things will be easy :-)


Am 29.07.2020 um 11:20 schrieb Ron Pressler:
> See the other responses about why you don’t “run out” of threads,
> but I think that the ability you ascribe to Go is selection, i.e. you 
> can wait
> on multiple channels at once. BlockingQueues are a little like 
> channels, but
> with some missing functionality, including selection. A more 
> channel-like class,
> with selection, is in now in development.

Awasome! After the reply from Alan that Continuation and 
ContinuatioScope will be locked away somewhen my first idea was that in 
that case a new Java BlockingQueue class with special support for 
virtual thread scheduling would make sense.