On Thu, Jun 26, 2014 at 3:23 PM, Harald Oehlmann <harald.oehlmann@elmicron.de> wrote:
Am 26.06.2014 10:30, schrieb Alexandre Ferrieux:
>
>
> On Thu, Jun 26, 2014 at 9:31 AM, Harald Oehlmann
> <harald.oehlmann@elmicron.de <mailto:harald.oehlmann@elmicron.de>> wrote:
>
>     I am asking for a sponsor within the TCT to start the vote on
>     "TIP 427: Introspection of Asynchronous Socket Connection".
>
>     http://www.tcl.tk/cgi-bin/tct/tip/427
>
>     Much background information is on the wiki page containing typical use
>     case scripts:
>
>     http://wiki.tcl.tk/socket%20-async
>
>     The implementation is ready on fossil branch tip-427.
>     The missing points are: documentation and tests.
>
>     The TIP itself says "targeting TCL 8.7" but I am targeting 8.6.2.
>     A backport to 8.5 is IMHO also a good thing.
>
>     Any comments and discussion welcome.
>
>
> Sorry to chime in so late, but I find the following sentence rather
> obscure, and a bit worrying:
>
>   "Each command which touches the socket (i.e. puts, gets, read and
> fconfigure) will implicitly
>    advance the connecting process (at least) one step further through
> its internal state machine,
>    i.e., try the next IP address in the list if the previous attempt
> failed."
>
> It might benefit from a bit of detail and a couple of illustrative
> examples ;-)

Alexandre,
thank you for your question.
I am not sure if I can answer on the "worry" component, but maybe
something should be formulated differently in the TIP.

Intention:

TCL 8.5:
set h [socket -async $host $port]
# Some other calculation which take time
# Connect passes completely in the background and succeeds or fails
# Now learn about an eventual error
fconfigure $h -error

The aim is to this also with TCL 8.6 with multiple target IP addresses.
At the moment, we have a loop in the tcl connect function, which tries
one after the other.
To keep the loop running, it is normally called by the event loop.
To allow event loop free operation as in TCL 8.5, we had the idea to
continue the loop (as a side effect) of each command which touches the
socket driver, e.g. on the functions which are called by gets, puts,
fconfigure.
Typically the new method "fconfigure -connecting" continues it.

Okay, I get the idea. Thus, the idiom is

       set sok [socket -async ...]
       while {[fconfigure -connecting]} {
            tend other business
       }
       puts $sok ...

Then there's the refinement of "I started async, then changed my mind and decided to get back to blocking connect". Here comes the idea of "advancing the state machine from within I/O primitives":

       set sok [socket -async ...]
       while {[fconfigure -connecting]} {
            tend other business
            if {[change my mind]} break
       }
       puts $sok ...

Do these two examples accurately cover the intention ?
If yes, then the worrisome part should be rewritten: I/O primitives don't "advance the state machine by one step", instead they block until its completion.
Am I missing something ?

-Alex