FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

Il 01 aprile 2012 19:43, James K. Lowden <jklowden AT freetds.org> ha scritto:
> On Sun, 1 Apr 2012 17:27:09 +0100
> Frediano Ziglio <freddy77 AT gmail.com> wrote:
>> Il giorno 01/apr/2012, alle ore 16:35, "James K. Lowden"
>> <jklowden AT freetds.org> ha scritto:
>> > On Sun, 1 Apr 2012 11:24:18 +0100
>> > Frediano Ziglio <freddy77 AT gmail.com> wrote:
>> >
>> >> Probably I'll rewrite this code using events (on Windows), for the
>> >> moment streams are also ok.
>> >
>> > Could you explain that a little bit?  Are you thinking of abandoning
>> > the winsocket API?
>>
>> No, socket are required to use tcp/ip. In this case socketpair is
>> used to stop select.
>
> I'm looking at the changes in mem.c 1.223 to use a socketpair.  I don't
> understand what you mean by "to stop select".  I don't understand why
> we need a pair of sockets.  To support MARS?
>

One reason is MARS, another is to support all cancellation cases in a
signal and thread safe way (I don't remember the exact combination
that causes problems but I start writing this code before MARS).

>>To do this in Windows you can associate a system
>> event to a socket with WSAEventSelect so you can wait for events with
>> WaitForSingleObject and stop it just setting the event. More Windows
>> style and less resources used. I think in Linux I could use event_fd.
>> Using socketpair is the more portable way.
>
> WaitForSingleObject() requires threads.  event_fd is not portable and
> not POSIX.
>

Windows always support threads. Yes, these are not portable
optimizations. And perhaps the gain is not as good as other
optimizations.

> We put a lot of work into making the network layer as portable and
> simple as possible.  (We could do more: I am not convinced we need to
> inhibit the Nagel algorithm, for example.)  I hope we will continue to
> use POSIX constructs wherever possible, and not introduce OS-specific
> calls unless there is no other choice.
>
> --jkl

In this case we decided to disable Nagle algorithm cause performance
was really poor with Nagle enabled and lot of small queries.

Yes, it seems that tcp during the years require a lot of tuning in
order to get what you want, there are a lot of low level stuff in
net.c that should perhaps be moved in some separate header/source.
Things like cork/nodelay/msgmore, signal/nosigpipe/nosignal,
gnutls/openssl, read/recv, keepalive and others I don't remember.

Frediano