For example, if I want to write a daemon program in C# that uses anonymous pipes to communicate with programs written in another language, is this both possible and feasible?
I ask because I intend to write the code in a language that can cross-compile to several targets (Haxe). I intend to write an application which compiles code on the fly, runs it, and communicates with it over a period of time, and other targets compile faster than C# (any scripted language for example), I can easily write common platform agnostic client code in Haxe, but is this possible and feasible in C# using the AnonymousPipeServerStream?
I see that the client handle is simply a strIng, what is this string for? How is it used to initialize the AnonymousPipeClientStream and can I create a cross-platform abstraction in client programs that similarly initializes and consumes the client handle from the .NET server application?
Most languages support subprocessing by running a shell command and returning an object with handles for the stdin, stdout and stderr streams for a program. This is, for example, a prerequisite to initializing an AnonymousPipeServerStream, the underlying program simply does something with a pipe handle, presumably this is more performant than using System.Diagnostics.Process.Stdin/Stdout?
How is this different than an anonymous pipe?
2 Answers 2
Based on further research, the short answer (to the primary question) is yes.
The answer to the second question depends on the language, for example, HashLink does indeed use Anonymous Pipes for subprocesses.
If the goal is to communicate between a c# program and some other program, I would suggest using some kind of messaging library rather than pipes.
The problem is that pipes do not handle messages, just bytes. So you would probably need to implement your own protocol on top of the pipe, and implement this again for each language you want to target.
Take ZeroMq as an example of a message queue. It has quite a few language bindings already available, and I suspect that at least some messaging frameworks support pipes for transport. But there are many other libraries/protocols to chose from.
You probably also want to consider serialization, this is much easier to manage with a good serialization library, and I suspect most languages has support for the most common formats, like json.
Process.Stdin/Stdoutfor IO, from reference source I can tell for most higher level language, without some FFI it's not possible to do exactly what Pipes do, as they use kernel level APIs.