Skip to Content.
Sympa Menu

freetds - Re: [freetds] done processing and token.c

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] done processing and token.c
  • Date: Thu, 13 Jan 2005 08:01:18 -0500

<Frediano.Ziglio AT vodafone.com> wrote:
> Today I started fixing problem using compute results.
>
> Mainly in token.c there are 5 function to process tokens
> tds_process_cancel
> tds_process_result_tokens
> tds_process_row_tokens
> tds_process_row_tokens_ct
> tds_process_trailing_tokens

Plus tds_process_default_tokens().

> As usually I never liked the use of tds_peek/tds_get_byte and similar in
> higher libraries.

I have never liked the organization of token.c, and I especially find it
hard to know who's reading the token.

TDS has a very predictable structure: token, length, data. The functional
flow should always be:

read token
read length (except login packet)
allocate memory
read data
call token handler, passing data
free data
send response, if any

Today, the token handler allocates memory and reads its own data. By
localizing that logic, libtds would become much easier to understand.
Most of libtds's job is *parsing* packets, but that's hard to see with its
read-a-byte, read-a-string, read-another-byte approach. I think
localizing the wire handling would lead to better cancel, done, and
timeout processing, too.

The cost, of course, would be a buffer copy. One "raw" packet buffer,
unparsed, read by the wire reader, and one parsed packet (a row buffer,
say).

Today, the token handler sometimes reads the next token and sometimes
determines the next function to call (which is sometimes itself). That
spaghetti calling chain constitutes implicit state information. It would
be better to keep the state information explicitly in the TDSSOCKET.

My idea is really two:

1. Have one token reader.
2. Have one packet reader.

If you think the cost of #2 is too high (especially for some tokens), we
could still have #1 (which would improve the logic flow), and keep some
(few) specialized packet readers for efficiency.

What do you think?

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page