FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

On Sun, 1 Apr 2012 22:57:04 +0100
Frediano Ziglio <freddy77 AT gmail.com> wrote:

> 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). 

Then I doubt it's necessary, strictly speaking.  Stevens shows tcp/ip
can (and should) be managed with one thread of control.  I would be
happy to help you meet your goals using just one socket, if you can
explain what led you to creating the pair.  

Signals and threads don't mix, as you know. 

> > WaitForSingleObject() requires threads.  event_fd is not portable
> > and not POSIX.
> 
> Windows always support threads. 

Yes.  Threads might not be the worst thing Windows brought to
programming, but they're close.  

The point isn't whether or not threads are supported.  The point is:
Do threads make the code easier to understand and reason about?  
The answer is almost always No.  

As I'm sure you agree, the more we can use portable constructs and a
single thread of source code, the better off we are.  

> And perhaps the gain is not as good as other optimizations.

The first rule of optimization is: measure.  FreeTDS is pretty
efficient as it is.  It would be easy to make it more complex without
making it any faster.  

The Big Optimization could come from my automaton.  Early
measurements indicate a state machine could manage the TDS layer with
about 10% of the code, no copies, and no mallocs (except for packets).  

I've taken some time to read about binary parsers e.g. binpac
http://www.bro-ids.org/documentation/components/binpac/README.html.
It's not clear to me that a parser-generator buys us anything over my
do-it-yourself approach.  But I'd like to be convinced before going
ahead.  

--jkl