Skip to content

JSONRPCConnection handled in swift instead of DispatchIO #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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

JSONRPCConnection handled in swift instead of DispatchIO #2315

Changes from all commits
Commits
Show all changes
4 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
8776228
Handle both sides as well as close()
roman-bcny Oct 16, 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
112 changes: 35 additions & 77 deletions Sources/LanguageServerProtocolJSONRPC/JSONRPCConnection.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,8 +58,9 @@ 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 sendIO: 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.

Copy link
Author

Choose a reason for hiding this comment

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

Naming follows JSONRPCConnection.init() args names, are you suggesting we change these as well?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I think changing the argument names JSONRPCConnection.init() would be my preference. Happy to change the argument names in a follow-up PR though, this PR is delicate enough that we don’t need to litter it with other renames. But I would prefer to name the members in here receiveFD and sendFD now already.

private let outFD: FileHandle
let ioGroup: DispatchGroup
Copy link
Member

Choose a reason for hiding this comment

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

Should this be private?

private let messageRegistry: MessageRegistry

/// If non-nil, all input received by this `JSONRPCConnection` will be written to the file handle
Expand All @@ -86,7 +87,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`.

Copy link
Author

Choose a reason for hiding this comment

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

yup I'll need to update the docs once this settles

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

Expand Down Expand Up @@ -136,45 +136,12 @@ public final class JSONRPCConnection: Connection {
state = .created
self.messageRegistry = messageRegistry

let ioGroup = DispatchGroup()

#if os(Windows)
let rawInFD = dispatch_fd_t(bitPattern: inFD._handle)
#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()
}
)
self.ioGroup = DispatchGroup()

#if os(Windows)
let rawOutFD = dispatch_fd_t(bitPattern: outFD._handle)
#else
let rawOutFD = outFD.fileDescriptor
#endif

ioGroup.enter()
sendIO = DispatchIO(
type: .stream,
fileDescriptor: rawOutFD,
queue: sendQueue,
cleanupHandler: { (error: Int32) in
if error != 0 {
logger.fault("IO error \(error)")
}
ioGroup.leave()
}
)
self.inFD = inFD
self.outFD = outFD

self.ioGroup.enter()

ioGroup.notify(queue: queue) { [weak self] in
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 the entire ioGroup is now just a convoluted way of saying: This should be executed when the connection is closed: This will get executed when ioGroup.leave() is called, which happens after calling closeAssumingOnQueue in JSONRPCConnection.close() and the error handler of JSONRPCConnectin.send.

So, if we just executed this code inside closeAssumingOnQueue, I think we could get rid of the entire ioGroup logic and greatly simplify this.

Incidentally, now that I look at this, we might have been missing a few ioGroup.leave() before as well.

guard let self else { return }
Expand All @@ -187,13 +154,6 @@ public final class JSONRPCConnection: Connection {
await self.closeHandler?()
}
}

// 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)
}

/// Creates and starts a `JSONRPCConnection` that connects to a subprocess launched with the specified arguments.
Expand Down Expand Up @@ -293,27 +253,19 @@ 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)")
self.inFD.readabilityHandler = { fileHandle in
let data = fileHandle.availableData
Copy link
Member

Choose a reason for hiding this comment

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

I unfortunately can’t remember the example when fileHandle.availableData has issues but I’ve been bitten by it more than once. I just remember that it’s a very delicate scenario where it misbehaves and it’s a pain to debug when it happens. So, I really want to use read(upToCount: Int.max)) here.

if data.isEmpty {
fileHandle.readabilityHandler = nil
self.queue.async {
self.closeAssumingOnQueue()
}
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 we need to return here. If we have set the readabilityHandler to nil and scheduled queue closing, we don’t have any further processing to do, do we?

Also, if data.isEmpty could then become a guard statement.

#endif
if done { self.closeAssumingOnQueue() }
return
}

if done {
self.closeAssumingOnQueue()
return
}

guard let data = data, !data.isEmpty else {
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?

Copy link
Author

Choose a reason for hiding this comment

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

I'm now using async in the last iteration, but I'm not sure I'm doing it right in each particular case

Copy link
Member

Choose a reason for hiding this comment

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

Why do you think we shouldn’t be using async here? My thought is that with sync, we are unnecessarily blocking the thread that handles the readabilityHandler while we are performing work on queue.

orLog("Writing input mirror file") {
try self.inputMirrorFile?.write(contentsOf: data)
}
Expand Down Expand Up @@ -554,16 +506,16 @@ public final class JSONRPCConnection: Connection {
orLog("Writing output mirror file") {
try outputMirrorFile?.write(contentsOf: dispatchData)
}
sendIO.write(offset: 0, data: dispatchData, queue: sendQueue) { [weak self] done, _, errorCode in
if errorCode != 0 {
logger.fault("IO error sending message \(errorCode)")
if done, let self {
// An unrecoverable error occurs on the channel’s file descriptor.
// Close the connection.
self.queue.async {
self.closeAssumingOnQueue()
}
sendQueue.sync {
Copy link
Member

Choose a reason for hiding this comment

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

Similar to my other sync vs async comment, I think we can make this async as well. The transmission of the data via stdout is asynchronous anyway, so as long as data is kept in-order (which it is using the queue), we should be able to handle sending in the background.

do {
try outFD.write(contentsOf: dispatchData)
} catch {
logger.fault("IO error sending message \(error.forLogging)")
self.queue.async {
self.ioGroup.leave()
self.closeAssumingOnQueue()
}
return
}
}
}
Expand Down Expand Up @@ -646,7 +598,10 @@ public final class JSONRPCConnection: Connection {
/// The user-provided close handler will be called *asynchronously* when all outstanding I/O
/// operations have completed. No new I/O will be accepted after `close` returns.
public func close() {
queue.sync { closeAssumingOnQueue() }
queue.sync {
closeAssumingOnQueue()
ioGroup.leave()
}
}

/// Close the connection, assuming that the code is already executing on `queue`.
Expand All @@ -660,9 +615,12 @@ 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.

Copy link
Author

Choose a reason for hiding this comment

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

I think I'm doing this now but might be doing it wrong :)

// Close the writer after it finishes outstanding work.
sendIO.close()
do {
try outFD.close()
} catch {
logger.error("Failed to close outFD: \(error.forLogging)")
}
Comment on lines +619 to +623
Copy link
Member

Choose a reason for hiding this comment

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

Can be simplified slightly.

Suggested change
do {
try outFD.close()
} catch {
logger.error("Failed to close outFD: \(error.forLogging)")
}
orLog("Closing outFD") {
try outFD.close()
}

}
}

Expand Down