in reply to IPC named pipe issue with nstore_fd
in thread IPC Design problem

I think your read loop in the Messaging class is a little too greedy:

ABORT:while(<$fh>){ my $data = $_; my $params = fd_retrieve($fh); ...

This first reads a line, then does an fd_retrieve(). Your test script first does an nstore_fd(), then writes some text, i.e. exactly the other way around.

This is not the only problem with your code. Apart from style/idiom issues, the fact that you are mixing plain text with binary text in the same channel is asking for trouble. If you reverse the writing order in your test script, the fact that the text string in our test script does not contain a newline will most likely trip up the <$fh> statement and slurp up the nstore-d data as well. (And if you have a string with more than one newline you also have a problem.) You should really consider using some appropriate encapsulation, like a hash with both the data and the parameters, written out with nstore:

# Writing a message: my $message = { data => "Some message\nthat can contain newlines\n", params => \%params, }; nstore_fd($message, $fh); # Reading a message: my $message = fd_retrieve($fh); my $params = $message->{'params'}; my $data = $message->{'data'};

... Or something like that.

Hope this helps!

-- Steven

Replies are listed 'Best First'.
Re^2: IPC named pipe issue with nstore_fd
by QuillMeantTen (Friar) on Aug 26, 2015 at 14:21 UTC

    Thanks for the tips, would you please expand on the "style/idiom issues"?

    I did not put much effort in applying best practices in the test script but I tried to do better in the code, what should I try to improve?

    also, I finaly nailed it down I think. I am still looking for a way to send serialized hash without bad things happening due to newline though...