Yes - a wrapper is good. For now you can use
set sock $env(HTTP_CHANNEL)
upvar #0 Httpd$sock data
inside that wrapper.
>>>Colin McCormack said:
> > The Thread_Dispatch function already hides the master's thread ID in
> > data(master_thread)
> > where data is the socket-related state array. So, if you do the
> > upvar #0 Httpd$sock data
> > hack, then you have access to this information.
>
> Yes, ok, I can see that would work in a direct procedure, but how about in
> .tml? I'm looking around, and can't find anything which would give the valu
e
> of $sock to a procedure called within a .tml.
>
> More generally, since we're passing data around in the global scope, and sin
ce
> we're using $sock to identify the specific connection context, I think it's
> reasonable to set some global somewhere which points to the current context
> (be it thread, or socket, or both.) In that way, we could write some wrappe
r
> functions to access the Httpd$sock values, and hide the fact that we're doin
g
> a global scope hack, and even pave the way to itcl object-, or tcl namespace
-
> encapsulation, which is probably neater (I doubt that this is a contentious
> statement :)
>
> Is there a consensus, or do you, Brent, have some preference? I'm prepared
to
> write such a wrapper, but would like to know that there's some chance of it
> being rolled in first.
>
> > >>>Colin McCormack said:
> > > Hi,
> > >
> > > May I make a suggested addition to lib/thread.tcl?
> > >
> > > In Thread_Start, around line 113, it would be most useful to have somet
hing
> > like:
> > >
> > > Thread_Send $id \
> > > [list set pid [thread::id]]
> > >
> > > So that each of the worker threads could access the parent's functional
ity.
> > >
> > > Alternatively, could threadmgr have a command to send a script to the m
aster
> > _thread for processing.
> > >
> > > The problem I'm trying to solve is one in which I'm using a web interfa
ce to
> > control a single process, the process is maintained (in some sense)
by th
> > e master thread, and so it's necessary to have that master thread arb
itrat
> > e between accesses by the worker threads.
> > >
> > > Which do you think is the better approach?
> > >
> > > Colin.
> > >
> > >
> >
> > -- Brent Welch <[EMAIL PROTECTED]>
> > http://www.ajubasolutions.com
> > Scriptics changes to Ajuba Solutions
> > scriptics.com => ajubasolutions.com
> >
> >
> >
> >
>
>
-- Brent Welch <[EMAIL PROTECTED]>
http://www.ajubasolutions.com
Scriptics changes to Ajuba Solutions
scriptics.com => ajubasolutions.com
