feat: context cancellation

[2-towns]

This PR add context and cancellation for UploadReader, UploadFile and DownloadStream.

[emizzle]

Nice Arnaud! I definitely like the Context addition 👍

[emizzle]

The way I understand this is that the context cancellation is checked only once and is non-blocking due to the default, after download is started. Would it be better to start a go routine and let it cancel the session so that context cancellation can be monitored continuously?

var cancelErr error
go func() {
    <-ctx.Done()
    cancelErr = node.DownloadCancel(cid)
}()
_, err = bridge.wait()
if err != nil { 
  // ...

I have one question though. If we call C.cGoCodexDownloadStream, then the context is cancelled and node.DownloadCancel is called, will the resources consumed in C.cGoCodexDownloadStream be cleaned up properly? I also find the ergonomics of the two calls to be oddly different:

C.cGoCodexDownloadStream
node.DownloadCancel

But both seem to go through the thread boundary back to nim. Or maybe I misunderstood something here?

[2-towns]

The way I understand this is that the context cancellation is checked only once and is non-blocking due to the default, after download is started. Would it be better to start a go routine and let it cancel the session so that context cancellation can be monitored continuously?

Oh yes you're right, thanks !

will the resources consumed in C.cGoCodexDownloadStream be cleaned up properly?

Yes it will. If there is a cancellation, the stream will be closed, the current call to cGoCodexDownloadStream will generate an error. The bridge.wait() will wait until the error is sent and the resources will be freed thanks to defer bridge.free().

[emizzle]

Out of curiosity, does this pattern not work?

var cancelErr error
go func() {
    <-ctx.Done()
    cancelErr = node.DownloadCancel(cid)
}()
if cancelErr != nil:
// ...

[2-towns]

Sorry I didn't reply directly to your pattern, but the problem is that the goroutine will leak because it will wait infinitely for cancellation.

We agreed on discord on using defer close(done) to close the goroutine after the function is done.

[emizzle]

We agreed on using defer close(done), but we don't need the select. The pattern would be like this:

done := make(chan struct{})
defer close(done)
channelError := make(chan error, 1)
go func() {
    select {
    case <-ctx.Done():
        channelError <- node.DownloadCancel(cid)
    case <-done:
        // Nothing to do, download finished
    }
}()

_, err = bridge.wait()

[emizzle]

Same comment as above re: go routine.

[emizzle]

Same as above re: no select needed.

[emizzle]

I'll approve now so that once download and upload are changed, this can be merged quickly 👍

[emizzle]

We agreed on using defer close(done), but we don't need the select. The pattern would be like this:

done := make(chan struct{})
defer close(done)
channelError := make(chan error, 1)
go func() {
    select {
    case <-ctx.Done():
        channelError <- node.DownloadCancel(cid)
    case <-done:
        // Nothing to do, download finished
    }
}()

_, err = bridge.wait()

[emizzle]

Same as above re: no select needed.