I believe Oracle has an async API you can invoke, but my initial thinking
was not to use it, but to use a general "future-thread" mechanism.
In this scenario, the SQL query started from Tcl is executed in C++ in a
separate thread of execution, the calling thread returns immediately. The
"executing thread" registers its completion by notifying an async handler
(via Tcl_AsyncCreate/etc) of its completion, so that the Tcl command to
read the results can occur.
This would be a general way to make ANY blocking call work asynchronously
in Tcl, with the multithreading occuring on the C++ side, rather than on
the Tcl side.
|--------+------------------------------>
| | Ted Dunning |
| | <tdunning@musicmatch|
| | .com> |
| | |
| | 08/03/00 04:28 PM |
| | |
|--------+------------------------------>
>--------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: "'Brent Welch'" <[EMAIL PROTECTED]>, John Buckman
<[EMAIL PROTECTED]> |
| cc: [EMAIL PROTECTED]
|
| Subject: RE: async page rendering for SQL ?
|
>--------------------------------------------------------------------------------------------------------------------------------------|
> There may be code inside the latest Sybtcl or Oratcl to do this. I
> know that Tom Poindexter was experimenting with this. There is
> apparently one issue, however, in that you can select() on the
> socket while you are wiating for the query to execute, but once you
> start getting rows back the Oracle APIs make it awkward or even
> impossible. I don't know the details, and I think it would be OK
> anyway as once you start getting rows it doesn't matter. The big
> wait ocurrs while the query is being processed.
Two things come to mind here,
first - a thread hack of the sort that makes sockets work on windows might
be useful here. The secondary thread would block while snarfing and when a
few rows are available, it would cause a read event. I don't know the best
mechanism for causing the read event, but it can't be hard if it is already
done in the core.
second - it is not true that the big wait only occurs before the rows come
spilling back. Some queries return LOTS of data and Oracle can be pretty
slow about coughing it up. It would be bad to block the server during a
large regurgitation just as it would be bad to block the server while
fetching a large file. Happily, the thread trick in (first) should make
this work nicely.
