FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> On Fri, 2004-02-06 at 16:48, ZIGLIO, Frediano, VF-IT wrote:
> > New idea is:
> > - if state is idle ignore cancel request 
> (tds_process_cancel should just
> > return on idle)
> > - if state is not idle cancel set a flag (send_cancel or whatever)
> > - on tds_write_packet test for cancel flag and send cancel (setting
> > cancel state too), so querying/processing automatically send cancel 
> > - updating state (ie from QUERYING to PROCESSING) test state (it
> > shouldn't be CANCEL)
> > This method seems less intrusive and simpler to implement. 
> 
> Hi,
> 
> I consider setting a flag for cancel and checking this flag at exactly
> one point in the code as a good thing. Using an additional state is
> problematic because the state is being checked at many places. When
> dealing with interrupts we must keep in mind that the state can be
> changed from outside of the current "processing flow".
> 

The key is change the way state is changed. We do not change state in
many places. state should be changed atomically (for full thread
safety), if state is idle only a thread can send a query. Problems
1- only a thread can send a query at a time
2- only a thread can process a token
3- only a thread should process cancel
4- many thread can set a cancel (and wait for cancel if needed), or
second cancel should return fail (thread cancel)
5- if a cancel is issued from same query/process thread we cannot
send/process cancel but we must return setting a cancel somewhere
(signal cancel)

A recursive mutex should protect stream processing (that can detected
testing state). Another thread can test if another thread is
processing/sending data just testing state. If signal function must set
cancel entering mutex must success (this is the reason of using
recursive mutexes) to avoid dead-lock however signal function must
detect if the thread is processing/sending data (care coding state
setting). However I don't know how to code recursive mutexes in all
platforms :(

> But why do you want to have tds_write_packet() check the flag 
> instead of
> tds_read_packet()? When retrieving results from the server, is there a
> place where tds_write_packet() is being called? If not, FreeTDS would
> never send the cancel until the whole result have been read.
> 

Well, you are right, I was just testing cancellation querying. Both
tds_read_packet and tds_write_packet should be changed.

freddy77