Skip to Content.
Sympa Menu

freetds - RE: [freetds] dbsetinterrupt + blocking reads from the server

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] dbsetinterrupt + blocking reads from the server
  • Date: Wed, 26 Mar 2003 14:49:39 -0500

> From: Thompson, Bill D (London) [mailto:ThompBil AT exchange.uk.ml.com]
> Sent: March 26, 2003 1:16 PM
>
> 1) If we do blocking reads from the server when waiting for
> the results of a query ? I think we do...

Looks like it, Bill. See calls to IOCTLSOCKET in src/tds/login.c and
READSOCKT [recv] in src/tds/read.c::goodread().

> 2) If so, what we would have to do to change these to
> non-blocking reads ?

Oy. Why? I don't understand how this could be related to what you're
seeing. Not that I necessarily would....

> 3) could we then code dbsetinterrupt ?

To do what? The dbsetinterrupt() description refers to chkintr() and
hndlintr(), neither of which my systems have. AFAICT, BSD systems map
interrupts to signals or something like that.

The last time I worked on an interrupt handler, we had a 1200 bps modem
sending data too fast to our 6 MHz 80286, so my skills are a little rusty.

My questions are innocent; I don't understand why poll(2) is better for us
than select(2). I do see a note on the NetBSD man page, "select() works
poorly if multiple processes wait on the same file descriptor" but don't
know anything about its significance.

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.





Archive powered by MHonArc 2.6.24.

Top of Page