Good morning everyone,
This thread was a month ago, but I just thought I should follow up in
case someone else runs into this later and has the same question.
I was able to work around this with no real problem by just spawning
off a new process and letting the parent die. I for some reason
thought that wouldn't work because stdin and stdout would go somewhere
else, but of course stdin and stdout of a spawned process default to
the same as the parent process.
I still find it confusing that a named pipe returns a 401 error, and
it would be interesting to know why that's the error returned, but I
was able to work around my particular problem, so I'm happy for now.
:-)
Thanks to everyone who replied,
MM
> 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
>> <webmaster@xxxxxxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxx
>> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|