read_piece_alert and streaming (continued from arvidn/libtorrent)

[SemiAccurate]

I skimmed the above, but I suspect the issue lies in not providing or wanting to add a synchronous wake up/alert mechanism when a piece is available, whether it was already available, or just became available. You are correct in that anacrolix/torrent does make that possible and guarantee that the read can occur.

All the alerts are asynchronous in libtorrent @anacrolix (not synchronous) The proposal has a read piece call that will notify (with an alert called read_piece_alert) when the specified piece is downloaded, and provides the piece data in a buffer. That's all.

I'm not sure it's appropriate to discuss anacrolix/torrent stuff specific here, but assuming it's relevant to your feature request here:

1. What is the purpose of having the implementation call a user specified readahead function when you already provide for the user to set the number of readahead bytes?

As the Reader read position moves through a stream as reads occur, it might be desirable to dynamically calculate readahead, rather than have to call back in and adjust it and occur overhead in correcting the client's readahead-based calculations after it had already made them with a previous value. For example if you are reading slowly you might reduce readahead, or you might balance it dynamically across the available cache space.

You talk about cache space, is this something your torrent library maintains and is configurable by the client? Or is this just a generic client side caching mechanism you're talking about that is not relevant to your library?

2. Why is your Reader implementation blocking when the programming world is moving to asynchronous interfaces that return results in an efficient non-blocking manner?

Because people are confused about function colouring and concurrency and think that async/await syntax and callbacks somehow make "asynchronous" code possible when it's an entirely different axis. This is opinionated, but see how Haskell and Go do concurrency vs. other languages. I'm not convinced all languages have the tradeoffs figured out but they're getting there. In short, my implementation in Go does use asynchronous I/O, and it's programmed against using a blocking API. Those are the separate axes.

I'm not sure what function colouring is (attaching an "async" keyword?), though I thought Go concurrency and the async/await mechanism pioneered by C# are fundamentally using the same thing under the hood: coroutines (but one is stackfull and the other is stackless.)

Your view is as you admit opinionated, and that these are different axes of consideration .. Do you have a post or article in mind that would help explain this view to me so that I may learn more about it?

anacrolix/torrent will wake up blocked Readers when their data is available (which could be immediately), and as many blocks/pieces that are available are stitched together as necessary to satisfy the Reader interface constraints.

I don't doubt your implementation is efficient, but why is it programmed against using a blocking API, and not an async/nonblocking API?

I don't know if libtorrent supports evicting pieces like anacrolix/torrent, but if it does, a synchronous API, or an asynchronous one that ensures that data is delivered before it is evicted would be required to match the behaviour.

You talk about evicting pieces, I guess your library maintains a cache of some sort that is user visible/configurable? Why?

Why do pieces necessarily need to be in a cache or main memory to be delivered to callers as part of a stream oriented Reader API? If they happen to be already downloaded and on disk or in an OS buffer (and not in the library maintained cache) can't they still be read and then delivered / stitched together with relevant pieces to be delivered to the caller?

[SemiAccurate]

@anacrolix I'm not sure though are you getting these GH notifications from @ mentions in your repo?

[anacrolix]

I don't have time to answer this right now. In the meanwhile if you want synchronous read requesting into your torrents, try just using anacrolix/torrent.

[SemiAccurate]

Well I'm just trying to understand things at this point. Let me know when you can continue our discussion.

[SemiAccurate]

@anacrolix I don't mean to sound ungrateful for your insight, though I would appreciate genuine engagement from you regarding my sincere attempt to understand your library, in between your regular duties here of answering others across the repo's Discussions and Issues over this past week.

[anacrolix]

You talk about cache space, is this something your torrent library maintains and is configurable by the client? Or is this just a generic client side caching mechanism you're talking about that is not relevant to your library?

This is as implemented by the storage implementation in use. For example file-based storages don't have any caching, but there are some piece-based storage wrappers that allow you to evict pieces as wanted pretty easily. By caching I mean that the data can go away later.

2. Why is your Reader implementation blocking when the programming world is moving to asynchronous interfaces that return results in an efficient non-blocking manner?

Because people are confused about function colouring and concurrency and think that async/await syntax and callbacks somehow make "asynchronous" code possible when it's an entirely different axis. This is opinionated, but see how Haskell and Go do concurrency vs. other languages. I'm not convinced all languages have the tradeoffs figured out but they're getting there. In short, my implementation in Go does use asynchronous I/O, and it's programmed against using a blocking API. Those are the separate axes.

I'm not sure what function colouring is (attaching an "async" keyword?), though I thought Go concurrency and the async/await mechanism pioneered by C# are fundamentally using the same thing under the hood: coroutines (but one is stackfull and the other is stackless.)

Go in general, and the anacrolix/torrent Reader interface are blocking APIs and are implicitly asynchronous under the hood. That is to say that Go will handle things using asynchronous APIs in its runtime. async/await is just an explicit syntax allowing asynchronous implementations underneath.

Your view is as you admit opinionated, and that these are different axes of consideration .. Do you have a post or article in mind that would help explain this view to me so that I may learn more about it?

I think this is the original post on function colouring. http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Why do pieces necessarily need to be in a cache or main memory to be delivered to callers as part of a stream oriented Reader API? If they happen to be already downloaded and on disk or in an OS buffer (and not in the library maintained cache) can't they still be read and then delivered / stitched together with relevant pieces to be delivered to the caller?

If you return events to the user asynchronously, the state may change between issuing the event and having the chance to act on it. For example if a piece or file becomes available, it may be evicted before the user code can use it. It's just a complication that synchronous events avoid (and bring different problems instead).

[SemiAccurate]

On a side note, I think Rust adding async/await, thus far, was a mistake (and didn't have to be, with its very strong typing it's ideal for solving this problem). I think there could have been a better way to do it, maybe something like Kotlin's implicit await, or the way Zig does it, where it's implicit and depends on the caller.

Well Rust creator Graydon Hoare is now working on Swift (I guess it's better pay.) The Swift folks motivated structured concurrency thusly:

"async/await is a language mechanism for writing natural, efficient asynchronous code. Asynchronous functions (introduced with async) can give up the thread on which they are executing at any given suspension point (marked with await), which is necessary for building highly-concurrent systems.

However, the async/await proposal does not introduce concurrency per se: ignoring the suspension points within an asynchronous function, it will execute in essentially the same manner as a synchronous function. This proposal introduces support for structured concurrency in Swift, enabling concurrent execution of asynchronous code with a model that is ergonomic, predictable, and admits efficient implementation."

Additionally, with respect to function coloring, type theorist Ted Kaminski (who also helped make the open source Kani Rust verifier for AWS, which additionally checks unsafe code) said this:

"Exposing asynchrony in our programming model does create a distinction between two different kinds of functions. But that distinction always existed, it just wasn’t visible. It was just always handled on our behalf.

For OS threading, that handling was blocking. For green threading, that handling is hoping that a true blocking case doesn’t sneak in somehow, because this is all handled behind the scenes.

Promises and async/await make it explicit. They do so with very small runtimes, and a relatively minimal “function coloring” problem. (Especially minimal if you buy the argument the I/O should be more segmented off from the rest of a program.)

It’s absolutely debatable whether making something explicit is better or not. One is not always universally superior. But when making it implicit means that we’re writing programs in a synchronous world-view that’s entirely at odds with how the world actually works, then I become skeptical that implicit is better.

Maybe it’s better if our mental model for how our program works is more in line with how the world actually works."

As I said, on the balance I would favor the marking of async functions explicitly, as well as a structured form of concurrency.

Btw Ted mentions runtime overhead. There are to be sure tradeoffs with either approach, though I can't help but think the runtime overhead (with the stackfull coroutines) is concretely relevant with your own library as this issue keeps popping up:

#762
#820

[SemiAccurate]

Just to clarify again, how Reader works, because it's a specific feature of anacrolix/torrent:

@anacrolix A bit of clarity on your clarification here: Is how Reader works specific to anacrolix/torrent or is it applicable to how Go works in general? Because you implement this interface that is actually part of Go.

(Hmm or did you mean it's a specific feature of anacrolix/torrent when compared to other torrent libraries in general?)

[anacrolix]

In Go, Reader is a blocking interface (the contract is to return what is available if possible, and if nothing is available to block). The runtime will park goroutines that make IO requests for data in io.Reader implementations wrapping typical things like disk and sockets and service them using asynchronous event loops and the like on systems that support it.

[SemiAccurate]

This paragraph by Roman Elizarov (of Kotlin fame) explains his reasoning on why marking async functions is on the balance better:
"We could eliminate suspend [async] modifiers from pure-Kotlin code, but should we? I’m inclining to answer no. Having to mark asynchronous functions with suspend modifier is a small price to pay, but in return you get better insight into your code. You immediately see which functions are allowed to perform potentially long communications and which are supposed to complete quickly. Take a look at channels in kotlinx.coroutines library. They are designed and operate very much like channels in Go. But in Kotlin you can see that send function on a channel is marked with suspend, while close is not, so you don’t have to read a single line of documentation to immediately see that send may suspend if no one is receiving on the other side of the channel, while close always completes immediately. It works the same way in Go, but here Kotlin type-system helps us better reason about the code by representing a part of documentation in the function’s type." ( https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d )

I like this.

Btw Roman Elizarov also has this to say in that same article about the design decisions of Swift compared to Kotlin:

"So, we mark asynchronous functions with suspend modifier in Kotlin and argue that it helps. Shouldn’t we apply the same argument to the call-sites of these functions and introduce some kind of await? Interestingly enough, if you read Async/await proposal for Swift, you find that its design is very similar to Kotlin Coroutines Design (it is direct, promise-free and uses continuations under the hood), but syntactically it follows C# tradition with async keyword to mark functions and await keyword on their call-sites, even though with promise-free design await can be made optional since compiler knows when asynchronous function is being invoked."

On a side note, I think Rust adding async/await, thus far, was a mistake (and didn't have to be, with its very strong typing it's ideal for solving this problem). I think there could have been a better way to do it, maybe something like Kotlin's implicit await, or the way Zig does it, where it's implicit and depends on the caller.

Well I'm generally wary of making types even stronger or do more work (though Go goes too far in the other direction) but yeah Kotlin seems to have struck a fine balance by eliding await.

Regarding function coloring, type theorist Ted Kaminski (who also helped make the open source Kani Rust verifier for AWS, which additionally checks unsafe code) said this:

"Exposing asynchrony in our programming model does create a distinction between two different kinds of functions. But that distinction always existed, it just wasn’t visible. It was just always handled on our behalf. For OS threading, that handling was blocking. For green threading, that handling is hoping that a true blocking case doesn’t sneak in somehow, because this is all handled behind the scenes. Promises and async/await make it explicit. They do so with very small runtimes, and a relatively minimal “function coloring” problem. (Especially minimal if you buy the argument the I/O should be more segmented off from the rest of a program.) It’s absolutely debatable whether making something explicit is better or not. One is not always universally superior. But when making it implicit means that we’re writing programs in a synchronous world-view that’s entirely at odds with how the world actually works, then I become skeptical that implicit is better. Maybe it’s better if our mental model for how our program works is more in line with how the world actually works."

As I said, on the balance I would favor the marking of async functions explicitly.

Note that Ted also touches on runtime overhead. There are to be sure tradeoffs with either approach, though I can't help but think the runtime overhead (with the stackfull coroutines) is concretely relevant with your own library as this issue keeps popping up:

#762
#820

[SemiAccurate]

This paragraph by Roman Elizarov (of Kotlin fame) explains his reasoning on why marking async functions is on the balance better:
"We could eliminate suspend [async] modifiers from pure-Kotlin code, but should we? I’m inclining to answer no. Having to mark asynchronous functions with suspend modifier is a small price to pay, but in return you get better insight into your code. You immediately see which functions are allowed to perform potentially long communications and which are supposed to complete quickly. Take a look at channels in kotlinx.coroutines library. They are designed and operate very much like channels in Go. But in Kotlin you can see that send function on a channel is marked with suspend, while close is not, so you don’t have to read a single line of documentation to immediately see that send may suspend if no one is receiving on the other side of the channel, while close always completes immediately. It works the same way in Go, but here Kotlin type-system helps us better reason about the code by representing a part of documentation in the function’s type." ( https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d )

I like this.

@anacrolix FWIW Roman Elizarov has this to say in that same article about the design decisions of Swift compared to Kotlin:

"So, we mark asynchronous functions with suspend modifier in Kotlin and argue that it helps. Shouldn’t we apply the same argument to the call-sites of these functions and introduce some kind of await? Interestingly enough, if you read Async/await proposal for Swift, you find that its design is very similar to Kotlin Coroutines Design (it is direct, promise-free and uses continuations under the hood), but syntactically it follows C# tradition with async keyword to mark functions and await keyword on their call-sites, even though with promise-free design await can be made optional since compiler knows when asynchronous function is being invoked."

On a side note, I think Rust adding async/await, thus far, was a mistake (and didn't have to be, with its very strong typing it's ideal for solving this problem). I think there could have been a better way to do it, maybe something like Kotlin's implicit await, or the way Zig does it, where it's implicit and depends on the caller.

Well I'm generally wary of making types even stronger or do more work (though Go goes too far in the other direction) but yeah Kotlin seems to have struck a fine balance by eliding await.

Regarding function coloring, type theorist Ted Kaminski (who also helped make the open source Kani Rust verifier for AWS, which additionally checks unsafe code) said this:

"Exposing asynchrony in our programming model does create a distinction between two different kinds of functions. But that distinction always existed, it just wasn’t visible. It was just always handled on our behalf. For OS threading, that handling was blocking. For green threading, that handling is hoping that a true blocking case doesn’t sneak in somehow, because this is all handled behind the scenes. Promises and async/await make it explicit. They do so with very small runtimes, and a relatively minimal “function coloring” problem. (Especially minimal if you buy the argument the I/O should be more segmented off from the rest of a program.) It’s absolutely debatable whether making something explicit is better or not. One is not always universally superior. But when making it implicit means that we’re writing programs in a synchronous world-view that’s entirely at odds with how the world actually works, then I become skeptical that implicit is better. Maybe it’s better if our mental model for how our program works is more in line with how the world actually works."

As I said, on the balance I would favor the marking of async functions explicitly.

Note that Ted also touches on runtime overhead. There are to be sure tradeoffs with either approach, though I can't help but think the runtime overhead (with the stackfull coroutines) is concretely relevant with your own library as this issue keeps popping up:

#762
#820

[SemiAccurate]

@anacrolix to continue our conversation in this thread if I may, I replied to you a week ago, I don't know if you received my message below..

This paragraph by Roman Elizarov (of Kotlin fame) explains his reasoning on why marking async functions is on the balance better:
"We could eliminate suspend [async] modifiers from pure-Kotlin code, but should we? I’m inclining to answer no. Having to mark asynchronous functions with suspend modifier is a small price to pay, but in return you get better insight into your code. You immediately see which functions are allowed to perform potentially long communications and which are supposed to complete quickly. Take a look at channels in kotlinx.coroutines library. They are designed and operate very much like channels in Go. But in Kotlin you can see that send function on a channel is marked with suspend, while close is not, so you don’t have to read a single line of documentation to immediately see that send may suspend if no one is receiving on the other side of the channel, while close always completes immediately. It works the same way in Go, but here Kotlin type-system helps us better reason about the code by representing a part of documentation in the function’s type." ( https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d )

I like this.

FWIW Roman Elizarov has this to say in that same article about the design decisions of Swift compared to Kotlin:

"So, we mark asynchronous functions with suspend modifier in Kotlin and argue that it helps. Shouldn’t we apply the same argument to the call-sites of these functions and introduce some kind of await? Interestingly enough, if you read Async/await proposal for Swift, you find that its design is very similar to Kotlin Coroutines Design (it is direct, promise-free and uses continuations under the hood), but syntactically it follows C# tradition with async keyword to mark functions and await keyword on their call-sites, even though with promise-free design await can be made optional since compiler knows when asynchronous function is being invoked."

On a side note, I think Rust adding async/await, thus far, was a mistake (and didn't have to be, with its very strong typing it's ideal for solving this problem). I think there could have been a better way to do it, maybe something like Kotlin's implicit await, or the way Zig does it, where it's implicit and depends on the caller.

Well I'm generally wary of making types even stronger or do more work (though Go goes too far in the other direction) but yeah Kotlin seems to have struck a fine balance by eliding await.

Regarding function coloring, type theorist Ted Kaminski (who also helped make the open source Kani Rust verifier for AWS, which additionally checks unsafe code) said this:

"Exposing asynchrony in our programming model does create a distinction between two different kinds of functions. But that distinction always existed, it just wasn’t visible. It was just always handled on our behalf. For OS threading, that handling was blocking. For green threading, that handling is hoping that a true blocking case doesn’t sneak in somehow, because this is all handled behind the scenes. Promises and async/await make it explicit. They do so with very small runtimes, and a relatively minimal “function coloring” problem. (Especially minimal if you buy the argument the I/O should be more segmented off from the rest of a program.) It’s absolutely debatable whether making something explicit is better or not. One is not always universally superior. But when making it implicit means that we’re writing programs in a synchronous world-view that’s entirely at odds with how the world actually works, then I become skeptical that implicit is better. Maybe it’s better if our mental model for how our program works is more in line with how the world actually works."

As I said, on the balance I would favor the marking of async functions explicitly.

Note that Ted also touches on runtime overhead. There are to be sure tradeoffs with either approach, though I can't help but think the runtime overhead (with the stackfull coroutines) is concretely relevant with your own library as this issue keeps popping up:

#762
#820

[SemiAccurate]

@anacrolix to continue our conversation in this thread if I may, I replied to you a week ago, I don't know if you received my message below..

This paragraph by Roman Elizarov (of Kotlin fame) explains his reasoning on why marking async functions is on the balance better:
"We could eliminate suspend [async] modifiers from pure-Kotlin code, but should we? I’m inclining to answer no. Having to mark asynchronous functions with suspend modifier is a small price to pay, but in return you get better insight into your code. You immediately see which functions are allowed to perform potentially long communications and which are supposed to complete quickly. Take a look at channels in kotlinx.coroutines library. They are designed and operate very much like channels in Go. But in Kotlin you can see that send function on a channel is marked with suspend, while close is not, so you don’t have to read a single line of documentation to immediately see that send may suspend if no one is receiving on the other side of the channel, while close always completes immediately. It works the same way in Go, but here Kotlin type-system helps us better reason about the code by representing a part of documentation in the function’s type." ( https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d )

I like this.

FWIW Roman Elizarov has this to say in that same article about the design decisions of Swift compared to Kotlin:

"So, we mark asynchronous functions with suspend modifier in Kotlin and argue that it helps. Shouldn’t we apply the same argument to the call-sites of these functions and introduce some kind of await? Interestingly enough, if you read Async/await proposal for Swift, you find that its design is very similar to Kotlin Coroutines Design (it is direct, promise-free and uses continuations under the hood), but syntactically it follows C# tradition with async keyword to mark functions and await keyword on their call-sites, even though with promise-free design await can be made optional since compiler knows when asynchronous function is being invoked."

On a side note, I think Rust adding async/await, thus far, was a mistake (and didn't have to be, with its very strong typing it's ideal for solving this problem). I think there could have been a better way to do it, maybe something like Kotlin's implicit await, or the way Zig does it, where it's implicit and depends on the caller.

Well I'm generally wary of making types even stronger or do more work (though Go goes too far in the other direction) but yeah Kotlin seems to have struck a fine balance by eliding await.

Regarding function coloring, type theorist Ted Kaminski (who also helped make the open source Kani Rust verifier for AWS, which additionally checks unsafe code) said this:

"Exposing asynchrony in our programming model does create a distinction between two different kinds of functions. But that distinction always existed, it just wasn’t visible. It was just always handled on our behalf. For OS threading, that handling was blocking. For green threading, that handling is hoping that a true blocking case doesn’t sneak in somehow, because this is all handled behind the scenes. Promises and async/await make it explicit. They do so with very small runtimes, and a relatively minimal “function coloring” problem. (Especially minimal if you buy the argument the I/O should be more segmented off from the rest of a program.) It’s absolutely debatable whether making something explicit is better or not. One is not always universally superior. But when making it implicit means that we’re writing programs in a synchronous world-view that’s entirely at odds with how the world actually works, then I become skeptical that implicit is better. Maybe it’s better if our mental model for how our program works is more in line with how the world actually works."

As I said, on the balance I would favor the marking of async functions explicitly.

Note that Ted also touches on runtime overhead. There are to be sure tradeoffs with either approach, though I can't help but think the runtime overhead (with the stackfull coroutines) is concretely relevant with your own library as this issue keeps popping up:

#762
#820