Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #74664 > unrolled thread
| Started by | Larry Martell <larry.martell@gmail.com> |
|---|---|
| First post | 2014-07-17 14:19 -0400 |
| Last post | 2014-07-17 14:19 -0400 |
| Articles | 1 — 1 participant |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Blocked thread Larry Martell <larry.martell@gmail.com> - 2014-07-17 14:19 -0400
| From | Larry Martell <larry.martell@gmail.com> |
|---|---|
| Date | 2014-07-17 14:19 -0400 |
| Subject | Re: Blocked thread |
| Message-ID | <mailman.11945.1405621181.18130.python-list@python.org> |
On Thu, Jul 17, 2014 at 2:09 PM, Chris Angelico <rosuav@gmail.com> wrote: > On Fri, Jul 18, 2014 at 4:03 AM, Larry Martell <larry.martell@gmail.com> wrote: >> On Thu, Jul 17, 2014 at 2:01 PM, Chris Angelico <rosuav@gmail.com> wrote: >>> On Fri, Jul 18, 2014 at 3:55 AM, Larry Martell <larry.martell@gmail.com> wrote: >>>> I can have as many connections to the db server as I want, that's not >>>> the issue. The issue is that my main thread seems to be blocked in the >>>> join(), so I guess I'm going to need a separate script. I was trying >>>> to avoid that. >>> >>> Right, but what you're trying to do is monitor the local thread, by >>> spinning off a thread to do the deletion and then keeping an eye on it >>> by attempting a timed join. I'm saying it'd probably be easier to do >>> the monitoring on the server end, via a second connection. (It most >>> likely doesn't need special database privileges, even; at least in >>> PostgreSQL, any user can see pg_stat_activity entries for the same >>> user.) That's usually going to be more reliable, plus the server can >>> tell you whether the deletion is blocked waiting for a lock or busy >>> writing to the disk or something else. >> >> Yes, I agree, but the second connection will have to be in a second >> script, not the main thread of the script I have. > > Maybe. I don't know what facilities Oracle gives you; it might be > possible to start a query asynchronously, with either a callback when > it's done or a poll for completion. Then another connection could be > used to keep an eye on the first one. But yes, doing it with a > completely separate script would be simpler in many ways. Or you might > be able to do the job with two threads. I do not think Oracle support async or non-blocking queries as Postgres does. But what I think I can do is not call join(), and just start monitoring the server when I kick off the thread with the mail sql it in.
Back to top | Article view | comp.lang.python
csiph-web