Conversation
Notices
-
It is reported, a server claiming to be a Gnusocial instance slows down communication via https the same way, spamd does it for spammers, just returning one char every x seconds. Thats why I cannot consider it a PEAR bug, since PEAR works correct, even if there is no timeout after 1 year. The socket is clearly alive.
If stream_select connects to pipes to local processes, maybe these pipes are non blocking, but what about the streams being delivered by these local processes? Are these non-blocking, too?
-
But thats what I'm talking about. Not timing out is correct behaviour. The socket is alive, since it delivers a char every x seconds.
There is no socket timeout.
Could you please tell me, where the pipe code resides, iomaster.php connects to? Please hurry, my name is no joke, I cannot rely on my memory for longer periods, that dissociation is not stable.
-
blocking vs. non-blocking.
But PHP's stream functions are *all* for non-blocking streams, to my knowledge, but it begins to become unclear to remember, I am not shure.
That is kind of a dirty corner and should be *very* carefully cleaned.
And let me hereby tell you, I appreciate your efforts a lot - thank you for your great work.
-
This is not a bug within PEAR. Even in that Gnusocial case, socket timeout is a timeout for sockets: The time since a socket disappeared. But that did not happen. There are a some additional, other durations that have been no attention paid before. We need to identify and define them by ourself as timeout.
-
I will review as soon as possible. Depends on if and when I can get back into that dissociation and remember details.