http://qs1969.pair.com?node_id=124273

deprecated has asked for the wisdom of the Perl Monks concerning the following question:

Apple, in their infinite wisdom, has broken SysV IPC (including semaphores, etc). This means that IO::File does not compile properly for me.
IO.xs: In function `XS_IO__Seekable_getpos': IO.xs:208: `sv_undef' undeclared (first use in this function) IO.xs:208: (Each undeclared identifier is reported only once IO.xs:208: for each function it appears in.) IO.xs: In function `XS_IO__File_new_tmpfile': IO.xs:252: `sv_undef' undeclared (first use in this function) make: *** [IO.o] Error 1
The above is what I get, if anyone cares or knows how to fix it. The above people said that PostgreSQL was fixed with a 'shim'... but all this C stuff is beyond me.

At any rate, I am using this code to poke a fifo:

open FIFO, "<foo" or die "$!\n"; while (<FIFO>) { chomp; print "$_\n"; open FIFO, "<foo" or die "$!\n"; }
Initially, I didnt have the second open. But it seemed that after it got input, it would close FIFO and crash. So the second open, I thought, would keep <FIFO> alive.

I was wrong. When I do this:

foreach word (foo bar baz bletch quux qip qua) echo $word > foo end
(thats csh, not perl, for the uninitiated), all I get is foo, bletch, and qip from the perl script. And randomly at that. Sometimes, I only get foo.

What I'm trying to do here is create a named pipe from which a perl script can read. I want to direct a log (such as Apache) to the named pipe and have postgres read it into a database so I can run webstats directly off of it, rather than just importing the stupid logfile into the database. That strikes me as unnecessary.

So I'd like to know if anyone has any ideas here. I thought IO::File might be able to help, but it looks like it's suffering from the same problems my named pipe is. Has anyone got another idea? Or perhaps, oh hope of hope, a fix for my IPC? (yes, I am aware there is a kernel patch, and that there is even a kext for darwin. However, I'm not going to use software that threatens it will render my baby scorch unusable!!).

Oh, and I forgot. "foo," above, is the named pipe.

Thanks,
brother dep

one final note... i dont want to hear any jabs at apple. I'm angry enough for everyone here.

update: The fix below worked. Bueno.

--
Laziness, Impatience, Hubris, and Generosity.

Replies are listed 'Best First'.
Undeclared symbol errors
by Fletch (Bishop) on Nov 09, 2001 at 07:52 UTC

    IO.xs:208: `sv_undef' undeclared (first use in this function)
    That looks like you're trying to compile an older version from when perl's symbols were `exported' by default. All of perl's symbols are prefixed with `PL_' now days (e.g. sv_undef is now really PL_sv_undef so that perl doesn't clog up your C namespace).

    If you've got an older XS module and get errors like this try adding POLLUTE=1 to your Makefile.PL arguments when you run it. See perldoc perlmodinstall and perldoc ExtUtils::MakeMaker for more details.

Re: Improvised pipes (code)
by kjherron (Pilgrim) on Nov 09, 2001 at 22:46 UTC
    As Fletch indicated, your problems building IO don't look like a problem with your OS's IPC, but rather some problem with the perl header files.

    Now, about this named pipe. Your writer repeatedly opens the pipe, writes one line of text to it, and closes the pipe. The reader repeatedly opens the pipe, reads one line of text from it, then closes the pipe.

    Something you need to realize about pipes is that they don't hold data independent of their writers and readers. You can't open a pipe, write some data, and close the pipe, leaving the data to be read by future reader. They don't work that way.

    When a writer opens a pipe, the open() blocks until a reader also opens the pipe. Then, all writes to the pipe are passed directly to the reader. If both reader and writer close the pipe while some data is waiting to be read, that data is lost.

    On top of that, the reader is doing buffered reads, which means that it's reading all available data from the pipe, not just one line's worth. The rest of the data is held inside an IO buffer, waiting for you to use <> again. When you close & reopen the pipe instead, you lose the buffered data.

    In short, you have a race condition between these two processes. If the writer manages to write two lines to the pipe before the reader reads, then the reader will read both lines at once, return one of them to your script, and throw the other line away when you close the pipe.

    To fix your writer, you just need to open the pipe once instead of multiple times. In bourne shell you could do this:

    for word in foo bar baz bletch quux qip qua do echo $word done > foo
    For you reader, something like the following should be fine:
    open FIFO, "<foo" or die "foo: $!\n"; while (<FIFO>) { chomp; print "$_\n"; }