I may be missing something, but if your concern about passing the iterator to another goroutine, is with closing the wait channel here <https://github.com/ncruces/go-sqlite3/blob/8adb83866bb079e5c2223957a504796d97563c57/ext/seq/push.go#L26> (which is indeed problematic), I think this change <https://github.com/ncruces/go-sqlite3/commit/306cfce6d2cbc8b3d96b72b8e47adc45b8cddd32> resolves that issue.
This has the caveat that there's some degree of parallelism introduced by moving the initial wait outside consumer: consumer may now run in parallel with the caller of Push, at least until it blocks ranging next. The coro version does not have this issue (coroutines start paused), and otherwise it seems the observable behaviour matches this new version better. Nuno On Wednesday 26 February 2025 at 14:37:54 UTC Ian Lance Taylor wrote: > On Wed, Feb 26, 2025 at 2:18 AM Nuno Cruces <ncr...@gmail.com> wrote: > > > > On Tuesday 25 February 2025 at 18:15:40 UTC Ian Lance Taylor wrote: > > > > I think what you're presenting is an argument for > > > > package iter > > > > // Push returns an iterator, a yield function, and a stop function. > > // The iterator will return all the values passed to the yield function. > > // The iterator will stop when the stop function is called. > > // This provides a way to flexibly convert a sequence of values into a > Seq. > > func Push[E any]() (seq iter.Seq[E], yield func(E), stop func()) > > > > > > I haven't been able to make this interface work to hide the goroutine > logic from the caller (which IMO is most of the point). > > > > I may be missing something but ISTM that for this to work (and when > implemented with channels) the caller of seq(yield) needs to run in its own > goroutine. > > So, if we return seq(yield), we force the caller of Push to then spin a > goroutine to call seq (and it becomes harder to enforce no parallelism). > > That's a fair point. I think that the communication between the > iterator and the yield/stop function can be done via coroutines, but > that doesn't quite fit the current coroutine implementation in the > runtime. > > My concern with your alternative is that it may be fragile. It should > be possible for the function to pass the iterator to another > goroutine, but it's not clear to me what will happen to the coroutines > in that case. With for/range the language inherently constrains what > can happen with the coroutines--and the code is still really > complicated with all kinds of special cases around panics and passing > the yield function around. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/ad9ca85d-93dc-494c-8dca-993cf082719bn%40googlegroups.com.
