InputStream/OutputStream implemented delegate and getBuffer

[amosavian]

This PR implements Stream's missing methods including delegate, scheduleInRunLoop and getBuffer methods.

[spevans]

@swift-ci please test

[spevans]

@swift-ci please test

[amosavian]

@spevans would you mind testing again?

[spevans]

@swift-ci please test

[parkera]

Awesome! Maybe a couple simple smoke tests to verify that it's all hooked up correctly?

[amosavian]

@parkera Please find tests. I'm not sure they would work.

[ianpartridge]

@swift-ci please test

[parkera]

Not sure what went wrong there.

[parkera]

@swift-ci clean test

[amosavian]

@parkera I've implemented getStreamsToHost(withName:port:inputStream:outputStream:) and getBoundStreams(withBufferSize:inputStream:outputStream:) functions but I did not push them due to a comment about autoreleasing pointers in file. Is this issue fixed? Or should I push their implementation and keep it disable?

[parkera]

Let's keep them disabled for now. The problem is that the "Autoreleasing" style of pointer is unavailable on Linux.

[amosavian]

@parkera Would you mind mentioning CI to test?
Other APIs which had auto releaseing parameters like NSCalendar and Scanner had replaced these functions with other ones, or used UnsafeMutablePointer instead.

[amosavian]

I still wonder why ClangImporter does not import Autoreleasing pointers as simple inout variables

[spevans]

@swift-ci test

[parkera]

Autoreleasing has a certain memory management connotation which I don't believe is possible to replicate with just inout.

[amosavian]

Apple can change swift foundation overlay in a way that omit that autoreleasepool. Something like this pseudocode:

open class func getStreamsToHost(withName hostname: String, port: Int, inputStream: inout InputStream?, outputStream: inout OutputStream?) {
    @autoreleasepool {
        var _inputStream: AutoreleasingUnsafeMutablePointer<InputStream?>?
        var _outputStream: AutoreleasingUnsafeMutablePointer<InputStream?>?
        self._getStreamsToHost(withName: hostname, port: port, inputStream: _inputStream, outputStream: _outputStream)
        inputStream = _inputStream.pointee.retain()
        outputStreeam = _outputStream.pointee.retain()
    }
}

[amosavian]

I don’t understand why test failed

[spevans]

@swift-ci test

[spevans]

Looks like the last test ran really slowly for some reason

[amosavian]

It seems XCTestExpectation.init method signature is different in linux and darwin. I’ll fix it.

[parkera]

@amosavian Agreed that we can improve that API. It's on our list.

[amosavian]

@spevans Sorry, would you mind re-test again?

[xwu]

@swift-ci please test

[xwu]

Hmm...
@swift-ci please test

[amosavian]

@parkera linux’s XCTest is unable to test asynchronous with multiple fulfilling. Would you if I disable tests until xctest team implement missing features?

[amosavian]

@spevans would you mind retest. I've disabled delegates' test until linux's XCTest can handle expectations with multiple fulfills. This should also resolve compiling issue for now.

[spevans]

@swift-ci test

[spevans]

@amosavian I ran the test you added on macOS against the native Foundation library and it failed there (it timed out).
Is it possible to rework the test to work correctly on macOS? Also is it possible to come up with an alternative way of testing the delegate without using the wait function so it can be run on Linux? Maybe setting some state and just sleeping for 1 second (I assume on a file stream the delegate should fire straight away)?

[amosavian]

@spevans You are right. Indeed delegate handle is never triggered. It works in playground when needsIndefiniteExecution is set to true. I tried to use your approach using sleep or Thread.sleep() with no success. Even I used DispatchQueue and Thread but test is failing.

[amosavian]

Changes:

• Get delegate object from CFStream instead of keeping it in variable
• Added isEqua()l and hash methods for streams
• Added test for get/set delegate property
• Unified schedule/delegate test for input and output stream [disabled with comments]

[amosavian]

@compnerd I've made InputStream bridgable to CFReadStream and OutputStream to CFWriteStream. But stream as CFReadStream emits compile error. Can you help what I am missing?

Implementing _CFSwiftBridge function pointers' section for streams remained todo as I don't know how to implement and which functions should be listed in.

[millenomi]

@amosavian There is a conflict on this patch now that the Mojave merge has landed. Can you fix that?

[amosavian]

@millenomi done

[millenomi]

@swift-ci please test

[millenomi]

Can this point to a specific SR and/or Radar # for follow-up work?

[amosavian]

I am not sure this is a bug or intended behavior. This code crashed in my Xcode. I guess SwiftFoundation fails to load CFNetwork and fill callback pointers in CFStream socket object. (Regarding SwiftFoundation target is primarily Linux and macOS Foundation works fine.)

[millenomi]

We can't cause SCF compiled on macOS to crash, because that's a development environment we would like contributors to use. And we should not be picking anything up from CFNetwork in that case either. :(

So something is amiss.

[amosavian]

I’m novice in C and unable to resolve this (don’t know how to fix dynamic loading), unfortunately. Thus I decided to disable the code and hope an expert would fix it later.
Interestingly, afaik no other member of CFReadStream cluster classes are able to use scheduling and I have to stick to socket.

[shahmishal]

The Swift project moved the default branch to main and deleted master branch, so GitHub automatically closed the PR. Please re-create pull request with main branch.

More detail about the branch update - https://forums.swift.org/t/updating-branch-names/40412