Re: [Tclhttpd-users] Re: Non-blocking subst?

[Brent W. <we...@pa...>]

Right - that's what the threaded option in TclHttpd is all about.

>>>Ted Dunning said:
 > 
 > 
 > Events won't work for what was originally required.  The issue is that in
 > the line
 > 
 >      ReturnToClient [subst $template]
 > 
 > if the return from subst is delayed by entering the event loop, additional
 > events that cause the same thing will wind up pushing additional stack
 > frames that cannot complete until THEIR version ReturnToClient is called.
 > This means that regardless of how TCL handles events, tclhttpd will still be
 > screwed and stack overflow is likely to result since the oldest events will
 > never be cleared until the newest event is completed and the newest event
 > can be blocked by an even newer event arriving.
 > 
 > The simplest (by far) way to do this is to build a thread that handles each
 > subst.  It needn't handle anything more if you want global state up to that
 > point although that entails moving everything that the template might
 > reference into the child thread.  If you want to avoid that complexity, then
 > you should just process the entire query in a thread.  If you need access to
 > structures in the main thread, you can always post events to the main thread
 > to ask for the pieces that you need.  In fact, if database handles can't be
 > shared, then this can be taken a step further by putting database access
 > stubs into the child thread that post scripts back to the database thread.
 > These can then be handled in an event-driven fashion and when the results
 > are available the original child thread can just call the threaded
 > ReturnToClient to send results back to the requestor.  This approach gives
 > you the best of event driven DB access along with the best aspects of
 > threads (i.e. independent stack and state).
 > 
 > 
 > >>>co...@fi... said:
 >  > I just had a quick look at the tcl implementation of events.
 >  > 
 >  > Events are processed in the order they occur on the event queue.  Quick 
 >  > perusal of the unix and generic uses of event queue shows that all events
 > to
 >       
 >  > be processed are placed at the end of the queue, and therefore will be 
 >  > serviced in order of arrival.
 >  > 
 >  > This implies, doesn't it, that all current events will be serviced before
 > an
 >      y 
 >  > new event, and therefore that no event will starve.
 >  > 
 >  > I think that it does what's required.
 >  > 
 >  > Colin.
 >  > 
 > 
 > _______________________________________________
 > TclHttpd-users mailing list
 > Tcl...@li...
 > http://lists.sourceforge.net/lists/listinfo/tclhttpd-users

--
Brent Welch
Software Architect, Panasas Inc
Pioneering Object-Based Network Storage (ONS)

www.panasas.com
we...@pa...