"Jim Starkey" <jas@...> wrote in message
news:42B03B27.8040400@......

>
> Any interrupt mechanism requires a second socket to send interrupt
> message (OOB data doesn't work on many/most/all TCP/IP
> implementations). This leaves two alernatives. Either the remote
> interface establishes a second (or third if events are active)

socket to

> enable interruptions, or we create a separate socket with a second
> attachment to transmit the interruption. There are at least two

However, it is possible to send interruption request using the
original socket. I even believe it can be done in the current SS TCP
listener without mass modification. Current TCP listener
implementation receives and dispatches packets asynchronously of
other threads executing them. So it can happily receive interruption
request and notify the worker thread to stop.
The client side should use some per-socket synchronization to keep
data separate and submit cancel requests from a different thread
since the primary thread is blocked.

I would like events to use the original socket as well.

> Going back to the security question raised above, let's try a

different

> tack. Rather than trying to verify permissions, why don't we use an
> unforgeable token like a guid? Then, if we see a valid token, we

can

> safely assume that it originated from the client wishing to snuff

out

> his request.

Yes, the current event logic has a similar security problem since
there is no authentication of secondary connections. There is a time
slice after a server opens the secondary socket and until the current
client connects to it when any TCP-enabled program in the world may
connect instead and hijack the events.

>>Fine. I only hope that the connectivity layer developers will never

decide

>>to unconditionally get tokens for every compiled request.

Why tokens? Use statement handle to identify running statement in the
same program if the program wants to cooperate in request cancelling
by itself. If a program doesn't want to cooperate to manage its
running queries, it will hardly provide you any tokens as well.

>>The only serious issue I see in your proposal is that it doesn't

support

>>isc_dsql_execute_immediate().

Not a big deal. If a client program itself wants to cancel its
request, it rather never use isc_dsql_execute_immediate. If someone
else wants to cancel others' running requests, it is no matter which
exact statement handle/token was used (if used at all).

Regards,
Aleksey Karyakin