> 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 value
of $sock to a procedure called within a .tml.
More generally, since we're passing data around in the global scope, and since
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 wrapper
functions to access the Httpd$sock values, and hide the fact that we're doing
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 something
> like:
> >
> > Thread_Send $id \
> > [list set pid [thread::id]]
> >
> > So that each of the worker threads could access the parent's functionality.
> >
> > Alternatively, could threadmgr have a command to send a script to the master
> _thread for processing.
> >
> > The problem I'm trying to solve is one in which I'm using a web interface 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 arbitrat
> 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
>
>
>
>
