`NSInputStream` produced by `Stream.toNSInputStream` can cause the isolate to hang

[brianquinlan]

toNSInputStream explicitly uses ports between Dart and the Objective-C shim:

native/pkgs/objective_c/lib/src/ns_input_stream.dart

Line 18 in 0028dd6

NSInputStream toNSInputStream() {

This can cause a hang if the user of the shim doesn't close it explicitly.

This is a problem for package:cupertino_http where the network loading framework will not call close if the HTTP request was aborted before open is called.

@liamappelbe I remember at some point callbacks changed their behavior in this regard. If I changed the implementation to use callbacks, would that fix the hang? I'm not sure how the current async callback implementation works.

[liamappelbe]

I don't think I understand the issue fully. When you say hang, do you mean a deadlock, or just that the isolate stays alive indefinitely? If it's the former, could you explain a bit more how a port not being closed causes a deadlock?

If it's the latter, you can choose whether a NativeCallable or an ObjC block keeps its isolate alive (.keepIsolateAlive = false). So yeah, you could migrate to callbacks and tell them not to keep the isolate alive. But RawReceivePort also has that setter, if that's easier for you to migrate to.

[brianquinlan]

Yeah, that was a crappy report, probably because I feel crappy today.

I meant that the ReceivePort never gets closed so that the isolate stays alive.