Use of connect syscall should support non-blocking

[hyln9]

Currently, the call to connect in do_connect in ikarus-io.c will block until the connection attempt succeeds or fails. I suggest that it not block when used via {tcp,udp}-connect-nonblocking. This is especially necessary for P2P programs designed around non-blocking sockets. Attached is a patch to do this.

(There's also a couple other minor changes: use io-error instead of die in two spots; check for EWOULDBLOCK also which is necessary for the accept syscall)

Launchpad Details: #LP258984 Derick Eddington - 2008-08-18 00:29:22 -0400

[hyln9]

I suggest this be fixed for 0.0.4.

Launchpad Details: #LPC Derick Eddington - 2008-12-30 05:01:09 -0500

[hyln9]

Attached is a program that demonstrates the problem of
tcp-connect-nonblocking blocking on the connect syscall.

Here's its output showing it block the server:

[d@eep:/t10]-> ikarus --r6rs-script connect-blocking.sps
Server sent. Time: 1231134607.189244000
Client received. Time: 1231134607.190330000
Server sent. Time: 1231134607.191223000
Client received. Time: 1231134607.191955000
Server sent. Time: 1231134607.192723000
Client received. Time: 1231134607.193476000
Server sent. Time: 1231134607.194231000
Client received. Time: 1231134607.195121000
Server sent. Time: 1231134607.196201000
Client received. Time: 1231134607.196485000
Server connecting... Time: 1231134607.197229000
Server connected. Time: 1231134607.438756000
Client done.
Server done.
[d@eep:/t10]->

Here's its output after the patch is applied:

[d@eep:/t10]-> ikarus --r6rs-script connect-blocking.sps
Server sent. Time: 1231135019.191153000
Client received. Time: 1231135019.192221000
Server sent. Time: 1231135019.193085000
Client received. Time: 1231135019.193377000
Server sent. Time: 1231135019.194168000
Client received. Time: 1231135019.194429000
Server sent. Time: 1231135019.195377000
Client received. Time: 1231135019.195639000
Server sent. Time: 1231135019.196395000
Client received. Time: 1231135019.196657000
Server connecting... Time: 1231135019.197373000
Server sent. Time: 1231135019.215267000
Client received. Time: 1231135019.215984000
Server sent. Time: 1231135019.216711000
Client received. Time: 1231135019.216977000
Server sent. Time: 1231135019.225119000
Client received. Time: 1231135019.225424000
[... a lot ...]
Server sent. Time: 1231135019.378400000
Client received. Time: 1231135019.378448000
Server sent. Time: 1231135019.378533000
Client received. Time: 1231135019.378580000
Server sent. Time: 1231135019.378663000
Client received. Time: 1231135019.378711000
Server connected. Time: 1231135019.387032000
Client done.
Server done.
[d@eep:/t10]->

Launchpad Details: #LPC Derick Eddington - 2009-01-05 01:07:00 -0500

[hyln9]

The patch attached to this bug report applies successfully to the
latest revision. However:

The patch from bug report #313852 (the 2nd non-typo one,
ikarus-io.patch) should be applied before the patch attached to this
bug report. The two patches conflict over 2 lines where they both do
"replace die with io-error". The patch from bug report #313852 should
be applied first because its "replace die with io-error" for those 2
lines uses other changes from the patch.

My patch program is able to successfully apply both:

[d@eep:/ikarus.dev]-> patch -p0 < ikarus-io.patch
patching file scheme/ikarus.io.ss
[d@eep:/ikarus.dev]-> patch -p0 < nonblocking-connect.patch
patching file scheme/ikarus.io.ss
Hunk #1 succeeded at 1406 (offset 172 lines).
Hunk #2 succeeded at 2346 (offset 173 lines).
Hunk #3 FAILED at 2498.
Hunk #4 succeeded at 2531 (offset 178 lines).
Hunk #5 succeeded at 2541 (offset 178 lines).
Hunk #6 FAILED at 2560.
2 out of 6 hunks FAILED -- saving rejects to file scheme/ikarus.io.ss.rej
patching file src/ikarus-io.c
Hunk #2 succeeded at 142 (offset 12 lines).
Hunk #3 succeeded at 166 (offset 12 lines).
[d@eep:~/ikarus.dev]->

The 2 failed hunks are the 2 lines I mentioned above and can be
ignored, and the 2 patches are still both applied as they should be.

Launchpad Details: #LPC Derick Eddington - 2009-01-05 01:20:36 -0500

[hyln9]

JTMI, the example connects to a host name and so does a potentially blocking DNS look-up. If an IP address instead was used (which would not cause a DNS look-up), the example would still have the problem of the connect syscall blocking. A real nonblocking application would use asynchronous DNS, which I hope can be made with Ikarus's nonblocking UDP support (I haven't looked into it yet).

Launchpad Details: #LPC Derick Eddington - 2009-01-09 13:23:27 -0500