Does anymore successfully read a named pipe created with mkfifo with BinaryStream ? The application crashes on the BinaryStream.Open command at least on OS X. Permissions and group/owner are ok.
[code] Dim readFile As New FolderItem(“path/to/your/fifo”, FolderItem.PathTypeShell)
If readFile <> Nil And readFile.Exists Then
readStream = BinaryStream.Open(readFile, False)
Timer1.Mode = Timer.ModeMultiple
Output.Text = Output.Text + readStream.Read(readStream.Length)
This probably isn’t going to work, but that’s an off the cuff guess. It shouldn’t crash though and that deserves a bug report (assuming it’s a hard crash that kills the app).
Being a named pipe I’m assuming this is a Windows app? If so I have a named pipe class available from here. Treat it like a TCP Socket & you’ll be right.
Clarification on this Joe? I’ve just started down the path of using named pipes/fifos for a multi-part app and that could mean disaster for the project.
For Mac you could use NSPipeMBS class in our plugins.
This is a class which will be used in a console app for Raspberry. Anyway, thanks for the code.
In fact the application doesn’t hard crash. It freezes and only a ‘Force Quit’ is able to stop the debug or standalone application.
In fact the application doesn’t hard crash. It freezes and only a ‘Force Quit’ is able to stop the debug or standalone application.[/quote]
Could you take a sample of the process with Activity Monitor and upload it somewhere so I could take a peek?
Here you go
Included one sample made with Activity Monitor and an another one which is one extract of what is shown by Problem Report application
Is it possible that you’re running into this behavior of FIFOs?
So, since I’m not going to connect until the backend tool is running and the fifos (read and write) are open, I should be fine?
Unfortunately, this one is for Linux…
you could of course email me with specs you need and I write a class for pipes…
Thanks. It looks like I’m okay so long as I follow the blocking rules when accessing the pipes from a BinaryStream. I always start the backend process before I try to connect, so this shouldn’t be an issue.
I tried with two applications. First one open the fifo with only read permission and freezes. The second one with write permission raise an ioexception with error code 45. Message property is empty. One sample for the application with write permission here
I’m probably wrong but for me pipe are standard Unix file and it shouldn’t be a big deal to to work with them.
They’re mostly standard files, but you can’t perform all of the operations on them that you could a standard file. One such unsupported operation is flock, which the framework calls when creating a file (presumably to have similar semantics to the old File Manager functions and Windows).
You could try using this instead of BinaryStream.Create:
Function CreateFile(f As FolderItem) As BinaryStream
Declare Function fopen Lib "System" (filename As CString, mode As CString) As Integer
Declare Function get_errno Lib "System" Alias "__error" () As Ptr // OS X specific way of reading errno
Dim handle As Integer = fopen(f.NativePath, "w")
If handle = 0 Then
Dim exc As New IOException
exc.ErrorNumber = get_errno().Int32
Return New BinaryStream(handle, BinaryStream.HandleTypeFilePointer)
It’s untested and was written in the forum text field at 6:30AM, but it looks like it should work. Give it a shot and also file a bug report in Feedback about being unable to deal with FIFOs.
@Wayne Golding the link is dead… could you please share again ?