Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Accessing the file descriptor fds.fd in Tcl_SetChannelOption

102 views
Skip to first unread message

tombert

unread,
May 23, 2018, 4:09:40 PM5/23/18
to
Hi,

I desperately need the tcp_nodelay option in tcl. Since 10 year old tips wait for their implementation (https://core.tcl.tk/tips/doc/trunk/tip/344.md) I thought of doing it myself.

The procedure Tcl_SetChannelOption gets the Channel passed.
Tcl_OpenTcpClient calls it with Tcl_SetChannelOption(interp, statePtr->channel, ...)

But in Tcl_SetChannelOption I need the statePtr->fds.fd (which is of type TcpState).

I'am confused on how to reveal the fds.fd inside the Tcl_SetChannelOption?

So, quick and dirty I did the following inside tclIO.c:

typedef struct TcpState TcpState;

typedef struct TcpFdList {
TcpState *statePtr;
int fd;
struct TcpFdList *next;
} TcpFdList;

struct TcpState {
Tcl_Channel channel; /* Channel associated with this file. */
TcpFdList fds; /* The file descriptors of the sockets. */
int flags;
...
...
}

Tcl_SetChannelOption:
...
if (HaveOpt(3, "-nodelay")) {
TcpState *tcpData = (TcpState*)chanPtr->instanceData;
int newMode;

if (Tcl_GetBoolean(interp, newValue, &newMode) == TCL_ERROR) {
return TCL_ERROR;
}
setsockopt(tcpData->fds.fd, IPPROTO_TCP, TCP_NODELAY, &newMode, sizeof(newMode));
...


-------------------------------------


Any "nicer" approach would be very welcome.

Question: Why is this TIP so much delayed? Can we expect this to be included in TCL 8.6? Can/shall I do it?

thx

Harald Oehlmann

unread,
May 24, 2018, 1:17:18 AM5/24/18
to
Tombert,

I am sorry for the TIP delay.
I recommend to contact Reinhard Max whether on the chat or via E-Mail.
Drop me an E-Mail (you find my on the wiki) if I should establish the
contact.
Reinhard cares about the general socket driver.
I am caring about the windows port.
And Donald or Andreas may get into play to look about the channel framework.

If you look to the file:
win\tclWinSock.c (here tcl 8.6.8 release), you have a define:
TCL_FEATURE_KEEPALIVE_NAGLE
which disables a lot of code.

Is this, what you are seeking for ?

We all hope to find implementors for TIPs and other code. No code, no vote.
I am specially seeking for an implementor for
https://core.tcl.tk/tcl/tktview?name=fc3c425cde ;-)

You may always dream.

You may write to Reinhard or myself in German. Drop me an E-Mail to chat
or even to have a phone call. We will try to support you.

Do you have commit access to core.tcl.tk/tcl ?

Thank you and best regards,
Harald

tombert

unread,
May 24, 2018, 6:06:04 AM5/24/18
to
Servus Harald,

thx for the support. I wrote an e-mail to Reinhard ... let's see if I got the correct address.

I have seen the disabled code in tclWinSock.c;
Since it is Windows specific I did not care about. I did my implementation in tclIO.c. It seems to work for Linux and Windows.
Interestingly I can reproduce the TCP delay in Linux very easily - it is adding about 40ms to each send operation. Doing a:
[chan <socket> configure -nodelay 1] brings it down to a few micros.
In windows it is always as if there is no Nagle algorithm enabled.

I have a login to core.tcl.tk, but no write access.
Depending on the "process" on committing something to the public I'll either opt for doing only patches for myself, or invest a little more and provide this update to the tcl86 core.

Thomas

Harald Oehlmann

unread,
May 24, 2018, 7:00:36 AM5/24/18
to
Ok, thanks.

Png me in case of questions.

Good luck,
Harald

m...@tclers.tk

unread,
May 27, 2018, 8:37:03 AM5/27/18
to
Hi Thomas,

tombert <tomber...@live.at> wrote:

> I wrote an e-mail to Reinhard ... let's see if I got the correct
> address.

yes, you did. :)

> I have seen the disabled code in tclWinSock.c; Since it is Windows
> specific I did not care about.

Actually only the error handling and some types in that code are Windows
specific, so it wasn't hard to do a version for Unix based on the
Windows code. I can commit it to a branch, if you are interested.

> I did my implementation in tclIO.c. It seems to work for Linux and
> Windows.

That's not the right place, because TcpState and TcpFdList are private
structs of tclUnixSock.c and tclWinSock.c, so accessing them from the
generic code would breach the layering of the Tcl channel system. That's
why the channel system has

BTW, if you compare tclUnixSock.c and tclWinSock.c, you'll see that
there is lots of dupliacted logic in there that only differs in types,
error handling and event notification. If that stuff got factored out, I
think 80..90% of the now platform specific socket code could be merged
and moved to generic/tclIOSock.c . I always wanted to do that, but never
got around to make it happen...

BTW2, to simplify adding support for more socket options in the future,
I would prefer to have a single new switch to fconfigure ("-sockopt" or
some such) that takes a dictionary of option names and values.

cu
Reinhard

Harald Oehlmann

unread,
May 28, 2018, 3:48:03 AM5/28/18
to
Reinhard,
thank you for answering and giving those valueable thoughts.
I am here for any possible action and support from the windows side.

Harald

tombert

unread,
May 29, 2018, 11:47:38 AM5/29/18
to
On Sunday, 27 May 2018 14:37:03 UTC+2, m...@tclers.tk wrote:
> Hi Thomas,
>
> tombert <> wrote:
>
> > I wrote an e-mail to Reinhard ... let's see if I got the correct
> > address.
>
> yes, you did. :)
>
> > I have seen the disabled code in tclWinSock.c; Since it is Windows
> > specific I did not care about.
>
> Actually only the error handling and some types in that code are Windows
> specific, so it wasn't hard to do a version for Unix based on the
> Windows code. I can commit it to a branch, if you are interested.

Why in a branch and not into the master?
I understand that TIP brings quality into the code, but so much talking about such a little thing as tcp_nodelay does not make sense to me.

>
> > I did my implementation in tclIO.c. It seems to work for Linux and
> > Windows.
>
> That's not the right place, because TcpState and TcpFdList are private
> structs of tclUnixSock.c and tclWinSock.c, so accessing them from the
> generic code would breach the layering of the Tcl channel system. That's
> why the channel system has

ok - so now I know why I had troubles accessing the pointer!

Harald Oehlmann

unread,
May 29, 2018, 12:53:46 PM5/29/18
to
Am 29.05.2018 um 17:47 schrieb tombert:
> Why in a branch and not into the master?
> I understand that TIP brings quality into the code, but so much talking about such a little thing as tcp_nodelay does not make sense to me.

We are sorry for that. The way to get included into TCL core might be
via a TIP and a vote.
So, it would be helpful, if you could reason the change.
As you wrote, on Windows, there is no effect. So, there might be some
reserch necessary.

Best regards,
Harald

tombert

unread,
May 29, 2018, 2:59:54 PM5/29/18
to
"no effect" means that there is out-of-the-box no delay visible (at least on my system). Seems as if Nagle's algorithm is implemented differently. I always have nearly 0 delay when sending packets.

I implemented a kind of remote eval over TCP. The "problem" I am facing is that when I do 100 remote evals (e.g. expr 1+1) it takes ~8 seconds because the TCP delay adds 2x40ms each (to remote and from remote). If I enable tcp_nodelay it gets executed in a few microseconds.

(To precise, the first [puts] is send immediately, but the rest of the 99 [puts] operations arrive with 40ms delay.)

0 new messages