Hey - I have a JVM desktop compose application, th...
# compose-desktop
s
Hey - I have a JVM desktop compose application, that is interacting with a kotlin native executable. Right now the Kotlin native is outputting json to stdio, and the jvm desktop app is watching the stdio and reading it in. The lag that i’m seeing with this method is several hundred millis surprisingly. Is there another communication method that you might recommend that would be faster?
1
z
This isn't a compose question, but there are many different IPC methods available depending on which desktop platform you're on. Also, how are you measuring latency?
e
is the pipe buffered, is the producer flushing, and is the consumer doing its own buffering?
but on the JVM side I would tend to go with sockets for more consistent behavior between platforms
l
Could you use the JNI? Right now, K/N using the JNI isn’t the cleanest thing in the world, but I’m using it at my work.
s
@ephemient I’m literally using println on the Kotlin native side. 😛 @Landry Norris Tried JNI, the underlying library that we’re accessing does much better when it’s process is just completely killed from memory between runs.
@ephemient sockets is an interesting idea, or heck, even the child process calling back into a server port on the host
j
unix domain socket?
e
socketpair on UNIX would be ideal but I don't know how to make that work with JVM (have to preserve FDs through fork somehow)
@spierce7 println() is probably buffered when stdout is not a console
I'm not 100% sure, though
s
Is there something different about a Unix Domain Socket than a normal socket that i just had open?
e
namespacing and permissions
s
I’ve never heard about them or how to use them. Guess I’ll try to do some reasearch
@ephemient funny enough after looking into this for a bit - Java has good support for Unix Domain Sockets. Finding out how to do them in Kotlin native / objc has been challenging.
Ktor has support for unix domain sockets actually
m
Which OS is this on? And by "lag" are you talking about process creation time or actual context switch time.
Process creation and context switching are both much slower on Windows than macOS/Linux.
UNIX domain sockets shouldn't make much difference vs just using stdio. Finally, are you sure you're immediately flushing stdout after writing?
s
are you sure you’re immediately flushing stdout after writing
I’m not.
m
Perhaps the delay is buffering induced?
s
After thinking about it some more, it seems likely that I’m probably reading line by line, and I’m not outputting a new line to get the value, so I’m not reading the last value until the process exits (something that I’ve noticed isn’t instantaneous as well)
a
I have successfully used plain sockets to communicate JVM <-> Native Darwin. A simple server socket running on Darwin apps, and a JVM client connecting to it.
s
I'm running benchmarks to see if it's faster tonight. I looked into buffered studio, and am flushing the buffer after every write now. I didn't see any performance benefit to that though.