On Mon, Feb 12, 2007 at 08:29:56PM -0500, Daniel Johnson wrote:
> Well, I found a problem. Turns out that lib/telnet.c calls Curl_poll
> on stdin, which is a device and therefore doesn't work with darwin's
> poll. In this case poll just spews POLLNVAL and curl goes into an
> infinite loop. :( Things are fine when select is used. So unless you
> want to special-case the code in telnet.c, Mac OS X will have to
> stick with select.

Fixing telnet support so it doesn't rely on stdin/stdout has been on the
TODO list for ages. Fixing that seems like the better solution.

And on that topic, what kind of solutions have been proposed for fixing
telnet? I don't recall hearing any in a long time, if ever. I suppose
it's not quite enough to simply use the CURLOPT_READFUNCTION and
CURLOPT_WRITEFUNCTION callback to read/write data instead of stdin/stdout.
After all, data could come from either side at any time and you can't
have either the library or the application blocking while data from
the other side is ready to come or go. Is it reasonable to restrict
use of telnet to the multi interface to get around this? Or, perhaps
force use of telnet into a request/response mode (which is a reasonable
limitation for most scripting applications), and follow each call to the
CURLOPT_WRITEFUNCTION with one to the CURLOPT_READFUNCTION (to which the
app can simply return 0 bytes)?

Has anyone though about any other options?

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved