Good morning Tom,
Thank you for your response! It's too bad things aren't as simple as I
think they should be. :-)
I do understand how named pipes work in general on Unix, how you must
have a reader and a writer for anything to happen.
If I create a named pipe and have no writer process, but then try to
more or cat that file, it just hangs waiting for a writer. Once data
goes in, the cat proceeds to dump it out as it should.
So my expectation was that apache would output nothing in response to
the GET request until data was being written to the pipe. I figure it
might time out after some period of nothing being written, but wasn't
counting on that. But a 401 error seems really weird to me, and I get
that whether or not there's a writer process on the named pipe.
I can accomplish what I want through CGI, but I was trying to work
around a process time limit on a shared server. The CGI script gets
killed if it runs too long, so my "brilliant" idea (so I thought!) was
to use a named pipe instead, and have the CGI program spawn off a new
process every so often to avoid being killed by the process time
limit. So much for that idea. Sounds like it's either back to the
drawing board, or on to a new host that doesn't impose this limit on
CGI program runtimes. (I could understand a limit on CPU time, but
their limit is on wall clock time, and the limit is only 2 or 3
minutes, which seems unreasonable to me.)
Thank You!
MM
> On Thu, Mar 22, 2012 at 1:56 PM, Mysterious Mose
> <webmas...@drdemento.com> wrote:
>> Good morning,
>>
>> [â¦]
>>
>> Â Â Why is this so difficult, and why aren't more people interested in
>> doing this? It seems like such a simple thing to do. If I create a
>> named pipe and write data to it, cat can get the data out, along with
>> many other programs. So why is apache different? Is it intentionally
>> trying to avoid reading data from named pipes, or is there some
>> low-level operating system issue that makes it difficult, which cat
>> has no problem with because it's part of the shell?
>>
>> Â Â Thank you for any insight!
>>
>
> I think you are thinking about this too simply. If you mkfifo a fifo,
> and then write data to it, you aren't actually writing data, as there
> are no readers of the fifo yet; the writing process is blocked waiting
> for the fifo to become writeable.
>
> Similarly, how should Apache deal with serving the fifo. Should it
> open it for both read and writes, ie allowing multiple writes to the
> fifo to appear in a single response, or should it open it just for
> reads, and punt as soon as one write is received. What should it do
> when there is no data to be read from the fifo?
>
> As you said, all these things are trivial, so I suggest you knock up a
> CGI that treats FIFOs as you want them to be treated and returns the
> data/times out as appropriate.
>
> Cheers
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
