Re: [TCLCORE] Why TclUnixWaitForFile ?

[Alexandre F. <ale...@gm...>]

On 6/15/08, Joe English <jen...@fl...> wrote:
>
> Alexandre Ferrieux wrote:
> >
> > While reviewing [patch 1960647]  Add ability to use poll() in
> > TclUnixWaitForFile()
> > https://sourceforge.net/tracker/index.php?func=detail&aid=1960647&group_id=10
> > 894&atid=310894
> >
> > I discovered the existence of this strange function. Can somebody give
> > me the rationale for it ?
>
> I was looking at this too not too long ago.
> Some things I found out:
>
> (1) TclUnixWaitForFile() is only used in one place in the
> core proper, namely WaitForConnect().
>
> (2) In WaitForConnect(), the "timeout" parameter is always either
> '0' (do not wait) or -1 (wait forever).  So TclUnixWaitForFile()
> is much more complicated than it needs to be -- it doesn't need the
> "mini-event loop" or all the timeout processing at all.
>
> (3) WaitForConnect() and the TCP_ASYNC_SOCKET/TCP_ASYNC_CONNECT
> logic is also more complicated than it needs to be (and might
> not be necessary at all).
>
> (4) TclUnixWaitForFile() is also used in the test suite, this time
> with timeout values > 0.  Whether the test suite is calling it simply
> to test TclUnixWaitForFile() itself or if it's needed to test
> something "real", I was not able to determine.
>
> (5) TclUnixWaitForFile also appears in the internal stubs table.
> Whether there are any callers outside of the core is difficult
> to determine.

OK, now way to remove a 13-year-old stub entry (see a 1995 mention by
JO in the changes file); I guess my cleanup plan will stop here :-)

> >  (a) why resync in that case, instead of just throwing an error "not
> > yet connected", relying on the caller to use the event loop as usual
> > to detect the completion of the connect phase ? (I know it's way too
> > late to change, I just want to understand)
>
> The idea is that [connect -async ...] won't block immediately,
> but subsequent reads or writes on the channel will.

Yes, this is pretty clear. What's not is "how is that usefult to the
script writer ?"

If I ask for an async connect, it is to use an event loop, or at least
a shorter-than-default timeout. In all cases I will have a fileevent
to detect connection completion.
Doing a "resyncing-IO" before that event is a bullet in my foot, since
I know it will block until the same instant as [connect without
-async] would have... Nonsense !

> >  (b) why is it unix-specific ?
>
> Probably because the Windows implementation uses a different
> algorithm for async connections.

Along the same lines, can you comment on the following comment in
TcpInputProc (the low-level reader for sockets):

 * NOTE: We cannot share code with FilePipeInputProc because here we must
 * use recv to obtain the input from the channel, not read.

Why ? What's wrong with read() on a socket in unix ?

-Alex