Yes.
This is exactly what I was suggesting. The only difference is that you have
researched it enough to actually make it work! :-)
It sounds like you are on your way. I can't wait.
-----Original Message-----
From: John Buckman
To: [EMAIL PROTECTED]
Sent: 8/9/00 12:45 PM
Subject: RE: async page rendering for SQL ?
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.
