Re: [Tclhttpd-users] Asynchronouse postgresql interface

[Brent W. <bre...@in...>]

>>>Colin McCormack said:
 > Brent,
 > 
 > Rather than expect someone else to unravel my strange terse (although 
 > copiously commented) code, if you can give me some pointers on how best to 
 > interface to tclhttpd, I'll make the mods.

Glad to help.

 > I note, on inspection, my lib is in itcl, which's a bit of a possible proble
     m, 
 > I guess.

We can simply do
package require itcl
no worries

 > Anyway, I suppose someone will want to execute an arbitrary command, say a 
 > select, on the postgresql backend, so what's the best way to do this in 
 > tclhttpd while servicing a page?
 > 
 > We've got an aexec primitive, which'll take a series of postgresql commands 
 > and call back to a proc with args when each one is complete (of course it 
 > works for n==1 too :)
 > 
 > We've got an rexec which'll set some var with the value of the result, at so
     me 
 > time in the future (when it's complete) and an mrexec, which'll append resul
     ts 
 > as they come in, from a series of postgresql commands.
 > 
 > Which'd be easiest to interface to tclhttpd?  What's the drill for making 
 > tclhttpd suspend processing of a page and finish up later?  What's the best 
 > way to cancel queries, and how will I know when they have to be cancelled?

Two answers.  A transparent way is simply:

Httpd_Suspend $sock
vwait whatever
Httpd_Resume $sock

The idea is that you can call Httpd_Suspend $sock
and the protocol engine will unregister all the fileevents and set
a timer.  Later on - say, in response to your postgres callback - you
call Httpd_Resume, and finish up with the Httpd_ReturnData.

The drawback of this approach is that it leaves
a bunch of stuff on the stack (The combined Tcl and C call stack).

You are pretty much stuck with this artifact (nested Tcl event loops)
unless you have a special DomainHandler that is willing to unwind its
action and restart it later.  You can raise a special error that'll unwind
the Tcl call stack and trigger a call Httpd_Suspend for you automatically.
However, if you were in the middle  the "subst" that is processing a .tml
page, you are hosed.  In general, it may be difficult to take advantage
of this feature.
 
 > There's a secondary matter here:  each postgresql connection can only perfor
     m 
 > one command at a time: the backend's singly threaded per connection, so 
 > there'd be some need to create a pool of open connections, or associate a 
 > connection with a session, or interlock a single pg connection to prevent 
 > multiple concurrent write attempts, or perhaps queue them.

If you have one connection per socket, then you'll stay single threaded.
Your cache could be indexed by $sock to see if you have one.
By the way, if you call
Httpd_CompletionCallback $sock $cmd
then the Httpd layer will call you back at the very end of the transaction.
You'll need that for cleanup.

 > I know I could hunt through tclhttpd to discover the answers to these Qs, bu
     t 
 > it may be quicker (certainly for me :) if you can shed some light on it for 
     me.

Happy to help.

--	Brent Welch	<bre...@in...>
	http://www.interwoven.com