3 ms·
Are you saying that Thread.sleep() will still be blocking its OS-thread completely so that this thread executes no other code until the end of the sleep call?
by valenterry 4y ago
Are you saying that Thread.sleep() will still be blocking its OS-thread completely so that this thread executes no other code until the end of the sleep call?
Because otherwise your claim "sync calls don't change" is wrong - since this is how it currently works.
- hota_mazi 4y agoThat's the very definition of what sleep() does, and the reason why, if you're calling it in an async context, you need to dispatch it in a special "blocking" dispatcher, as opposed to the other regular async calls.
- valenterry 4y agoThat doesn't answer my question to the OP. I know what sleep() does and how to use it, but that's not the point.
- pestatije 4y agoWe are talking virtual threads here(project loom), i think, no? https://openjdk.org/jeps/428 https://openjdk.org/jeps/428 Basically, you don't have a thread context anymore, or you don't have a use for it anymore
- valenterry 4y ago> We are talking virtual threads here(project loom), i think, no? No. Currently, when I have code (not using futures or anything) and in the middle there is a Thread.sleep() then I know that this thread will be blocked until the sleep is over (or interrupted) and _no other code is being executed on this thread_. So the question is: will this behaviour change? Because if it does, then Loom breaks existing code. And that's what it does. And it does it not by accident but on purpose, to retroactively improve performance of exactly those situations where OS threads are blocked.
- pestatije 4y agoah ok i see your single thread is blocked nevermind