I found some strange behaviour using async_connect when connecting to unbound ports on localhost. The callback is never called. Try something like this:
void cb(mixed ... args) { write("cb: %O\n", args); }
int main () { object o = Stdio.File();
o->async_connect("127.3.3.5", 3245, cb); return -1; }
A reason I found for that (not sure if there are more issues, it fixes this problem though) is that
1) in __stdio_close_callback() read(0,1) is used to check if data can be read from the socket instead of peek(). 2) file_peek() does not check for POLLERR or POLLHUP and therefore returns true even if the socket has been closed or some error occured
using peek() instead of read(0,1) in __stdio_close_callback() and adding
}else if (fds.revents & (POLLERR | POLLHUP)){
ret=0;
to file_peek() fixed this issue for me.
The same problem may occur when using select() in file_peek(), I did not test that though.
arne
using peek() instead of read(0,1) in __stdio_close_callback() and adding
}else if (fds.revents & (POLLERR | POLLHUP)){ ret=0;
to file_peek() fixed this issue for me.
Thanks for the suggestion. I've now added a second optional argument to peek() to specify a behaviour similar to the above.
The same problem may occur when using select() in file_peek(), I did not test that though.
Probably. I haven't tested either.
arne
I still would like to see a fix to the async_connect issue. Using the new peek() version in __stdio_close_callback helps, but i guess its a little more complicated. also I have not found a workaround...
I still would like to see a fix to the async_connect issue. Using the new peek() version in __stdio_close_callback helps, but i guess its a little more complicated. also I have not found a workaround...
peek() can currently not be used there since it doesn't exist on Windows (that ought to be fixed, though).
Note that neither read(0,1) nor peek() is used in that spot in 7.7; only the !errno() check remains. That happened with this somewhat cryptic comment:
revision 1.222 date: 2006/05/31 18:34:06; author: grubba; state: Exp; lines: +2 -4 peek() doesn't do what most people think it does...
What is it that most people have missed about peek()? And more importantly, does the code work correctly without any check on the read buffer? Upon an error free remote close, won't errno() return zero there?
peek() can currently not be used there since it doesn't exist on Windows (that ought to be fixed, though).
Fixed.
Note that neither read(0,1) nor peek() is used in that spot in 7.7; only the !errno() check remains. That happened with this somewhat cryptic comment:
revision 1.222 date: 2006/05/31 18:34:06; author: grubba; state: Exp; lines: +2 -4 peek() doesn't do what most people think it does...
What is it that most people have missed about peek()? And more
They think that peek() returning 1 means that there's data available.
importantly, does the code work correctly without any check on the read buffer? Upon an error free remote close, won't errno() return zero there?
Yes? So read() will return "" and the close callback will be called.
On Sun, Jul 29, 2007 at 11:55:02AM +0000, Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum wrote:
What is it that most people have missed about peek()? And more
They think that peek() returning 1 means that there's data available.
are you talking about Stdio.File()->peek(), or peek() on the c level?
if it doesn't mean there's data available, then what does it mean?
greetings, martin.
ok,
that is useful to know. i guess the docs for Stdio.File()->peek() should be fixed then, because they say:
Returns 1 if there is data available to read
maybe something like:
Returns 1 if read() can be called without blocking
greetings, martin.
i guess the docs for Stdio.File()->peek() should be fixed then, because they say:
Returns 1 if there is data available to read
?? As far as I can see, the documentation says the following:
*! Check if there is data available to read, *! or wait some time for available data to read. *! *! More specifically, a later call to @[read()] will return *! immediately, either due to data being present, or due to *! some error (eg if a socket has been closed).
my bad, i was looking at the docs from the last successful xenofarm build before the peek changes, and missed the doc changes.
docs are clearer now...
greetings, martin.
peek() can currently not be used there since it doesn't exist on Windows (that ought to be fixed, though).
Fixed.
Great! Is it tested?
Not yet. The change was minimal (prefix select() with fd_ (all the other operations were already prefixed), and remove the #ifndef __NT__). It compiles, and I don't see any reason why it would work any worse than on the other select()-based peeks (ie the BSDs).
pike-devel@lists.lysator.liu.se
-
Arne Goedeke ＠ Pike developers forum -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum
-
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum
-
Martin Baehr -
Martin Bähr
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum