Skip to content

Prototype pipe handling without dispatch IO #2315

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
+10 −37
Draft

Prototype pipe handling without dispatch IO #2315

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f1c8629
Prototype pipe handling without dispatch IO
roman-bcny Oct 1, 2025
cef0d4e
Switch to readabilityHandler
roman-bcny Oct 7, 2025
a4dfcf1
Use readData instead of availableData
roman-bcny Oct 7, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 10 additions & 37 deletions Sources/LanguageServerProtocolJSONRPC/JSONRPCConnection.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,7 +58,7 @@ public final class JSONRPCConnection: Connection {
/// The queue on which we send data.
private let sendQueue: DispatchQueue = DispatchQueue(label: "jsonrpc-send-queue", qos: .userInitiated)

private let receiveIO: DispatchIO
private let inFD: FileHandle
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we match the previous naming and call this receiveFD? inFD can get confusing if you eg. set up a JSONRPCConnection from SourceKit-LSP to a BSP server, in which case the receiveFD will be stdout of the BSP server process and thus receiveFD wouldn’t be stdin.

private let sendIO: DispatchIO
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we should replace this to be symmetric with the read side.

private let messageRegistry: MessageRegistry

Expand Down Expand Up @@ -86,7 +86,6 @@ public final class JSONRPCConnection: Connection {
/// Buffer of received bytes that haven't been parsed.
///
/// Access to this must be be guaranteed to be sequential to avoid data races. Currently, all access are
/// - The `receiveIO` handler: This is synchronized on `queue`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We now have a corresponding use in self.inFD.readabilityHandler, so we should include that here:

  /// - The `inFD.readabilityHandler`: This is synchronized on `queue`.

/// - `requestBufferIsEmpty`: Also synchronized on `queue`.
private nonisolated(unsafe) var requestBuffer: [UInt8] = []

Expand Down Expand Up @@ -140,23 +139,12 @@ public final class JSONRPCConnection: Connection {

#if os(Windows)
let rawInFD = dispatch_fd_t(bitPattern: inFD._handle)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need rawInFD?

self.inFD = inFD
#else
let rawInFD = inFD.fileDescriptor
#endif

ioGroup.enter()
receiveIO = DispatchIO(
type: .stream,
fileDescriptor: rawInFD,
queue: queue,
cleanupHandler: { (error: Int32) in
if error != 0 {
logger.fault("IO error \(error)")
}
ioGroup.leave()
}
)

#if os(Windows)
let rawOutFD = dispatch_fd_t(bitPattern: outFD._handle)
#else
Expand Down Expand Up @@ -188,10 +176,6 @@ public final class JSONRPCConnection: Connection {
}
}

// We cannot assume the client will send us bytes in packets of any particular size, so set the lower limit to 1.
receiveIO.setLimit(lowWater: 1)
receiveIO.setLimit(highWater: Int.max)

sendIO.setLimit(lowWater: 1)
sendIO.setLimit(highWater: Int.max)
}
Expand Down Expand Up @@ -293,27 +277,17 @@ public final class JSONRPCConnection: Connection {
state = .running
self.receiveHandler = receiveHandler
self.closeHandler = closeHandler
}

receiveIO.read(offset: 0, length: Int.max, queue: queue) { done, data, errorCode in
guard errorCode == 0 else {
#if !os(Windows)
if errorCode != POSIXError.ECANCELED.rawValue {
logger.fault("IO error reading \(errorCode)")
}
#endif
if done { self.closeAssumingOnQueue() }
return
}

if done {
self.closeAssumingOnQueue()
return
}

guard let data = data, !data.isEmpty else {
self.inFD.readabilityHandler = { fileHandle in
let data = (try? fileHandle.read(upToCount: Int.max)) ?? Data()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of try?, I would prefer to use orLog so that we log the error thrown by read(upToCount:).

if data.isEmpty {
fileHandle.readabilityHandler = nil
self.close()
return
}
}

self.queue.sync {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

self.queue.async should be sufficient here, it still guarantees that all incoming data is handled in-order and frees up the thread that the readability handler is running on. Or do you think I’m missing something?

orLog("Writing input mirror file") {
try self.inputMirrorFile?.write(contentsOf: data)
}
Expand Down Expand Up @@ -660,7 +634,6 @@ public final class JSONRPCConnection: Connection {

logger.log("Closing JSONRPCConnection...")
// Attempt to close the reader immediately; we do not need to accept remaining inputs.
receiveIO.close(flags: .stop)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we set the readabilityHandler of inFD to nil here to ensure that we don’t receive any more messages? If we do so, I think we also no longer need to set fileHandle.readabilityHandler = nil if data.isEmpty in the readabilityHandler.

// Close the writer after it finishes outstanding work.
sendIO.close()
}
Expand Down