Thread scoped variables
Locked
 
|
Hi,
I've seen two patterns in use in visualworks for having a variable bound to a certain thread of execution. The first is using 'Processor activeProcess environmentAt:[put:]', the second one is Seaside's 'WADynamicVariable use:during:'. Both seem to have problems, in that they don't like to be debugged. - What do you use out there? - Are there ways to make it more debugging friendly? Tnx, Wouter |
|
|
Wouter I am not familiar with the seaside
technique, however I do know if you want to use dynamic process variables
that can be debugged, you could simply add another instance
variable to process and use a dictionary to store your variables. This
will work just fine as long as you don’t try to access it from another
process, other than a debugging tool. Terry From:
[hidden email] [mailto:[hidden email]] On Behalf Of Wouter Gazendam Hi, |
|
|
I'm guessing that the problem Wouter experienced with #environmentAt:[put:] is
that the debugger runs in a separate process. The debugger process doesn't return values
stored for the debugged
process; execute:
Kernel.Processor
activeProcess environmentAt: #test put: 'here'. self halt. Kernel.Processor activeProcess environmentAt: #test then try to find the value stored for #test from
within the debugger. There is no obvious way to gain a reference to the process
being debugged so that you can send messages to it. The debugger process returns
environment variables for itself.
Terry, are you suggesting to modify the schema
of the Process class to add a variable that the debugger will somehow know to
reference? It seems like this would fail for the same reason; the debugger
process is not the same as the process being debugged. Perhaps you are
suggesting something else, like to declare a variable within the execution stack of the
process something like this:
| myProcess |
(myProcess := Kernel.Processor activeProcess) environmentAt: #test put: 'here'. self halt. Kernel.Processor activeProcess environmentAt: #test. myProcess environmentAt:
#test.
That
may help by providing a process reference somewhere deep in stack, but it
doesn't really make the debugger behave as if working with the process being
debugged. That approach isn't likely to be practical even if set earlier in the
same stack.
I have
a debugger implementation idea, Terry. Can you configure the environment of the
new debugger process to be a #newSubEnvironment of the #environment of the
process being debugged? The debug process would then read variables stored in
the debugged process but would not be able to update them (except through
#parentEnvironment). Sorry, I haven't poked around the debugger code to see if
this is practical; it is just an approach to consider.
I
haven't seen the seaside code but it seems the weak point is the 'during' block;
if it blocks other processes during execution then that would be bad for
debugging with a separate process--unless made to
allow reentrance for the debug process too.
Wouter, an approach I've used to portably implement the
same kind of thing you are attempting is to use a weak key identity dictionary
as a reference collection from within application code. It would have the same
kind of debug difficulties though. Perhaps you can give an example of why you
find debugging difficult with #environmentAt:[put:] so we aren't looking for
solutions to the wrong problem. Paul Baumann From: Terry Raymond [mailto:[hidden email]] Sent: Tuesday, June 26, 2007 9:04 AM To: 'Wouter Gazendam'; 'vwnc' Subject: RE: Thread scoped variables Wouter I am not familiar with
the seaside technique, however I do know if you want to use dynamic
process variables that can be debugged, you could simply add
another instance variable to process and use a dictionary to store
your variables. This will work just fine as long as you don’t try to
access it from another process, other than a debugging
tool. Terry From:
[hidden email] [mailto:[hidden email]] On Behalf Of Wouter Gazendam Hi,
|
|
|
Paul I am not quite sure what you mean. When I
execute the following doit, and then step when the debugger pops
up. Kernel.Processor
activeProcess environmentAt: #test put: 'here'. The debugger shows ‘here’ as
the result of the #environmentAt:. If you are thinking of performing a doit
on “Kernel.Processor activeProcess
environmentAt: #test” from within the debugger, that will not
work. A simple solution to this problem would be to add a menu
command that will open an inspector on the process being
debugged. The debugger is a process faithful
debugger when executing debugger control commands. However, it is
not process faithful for doIts, printIts, and inspectIts. The problem I am referring to is that the
window manager also uses the environment dictionary and when
the debugger steps into #environmentAt: the debugger may deadlock. Terry From: Paul Baumann
[mailto:[hidden email]] I'm guessing that the problem Wouter
experienced with #environmentAt:[put:] is that the debugger runs in a separate
process. The debugger process doesn't return values stored for
the debugged process; execute: Kernel.Processor
activeProcess environmentAt: #test put: 'here'. then try to find the value stored for
#test from within the debugger. There is no obvious way to gain a reference to
the process being debugged so that you can send messages to it. The debugger
process returns environment variables for itself. Terry, are you suggesting to modify the
schema of the Process class to add a variable that the debugger will somehow
know to reference? It seems like this would fail for the same reason; the
debugger process is not the same as the process being debugged. Perhaps you are
suggesting something else, like to declare a variable within the
execution stack of the process something like this: | myProcess | myProcess
environmentAt: #test. That may help by providing a process
reference somewhere deep in stack, but it doesn't really make the debugger
behave as if working with the process being debugged. That approach isn't
likely to be practical even if set earlier in the same stack. I have a debugger implementation idea,
Terry. Can you configure the environment of the new debugger process to be a
#newSubEnvironment of the #environment of the process being debugged? The debug
process would then read variables stored in the debugged process but would not
be able to update them (except through #parentEnvironment). Sorry, I haven't
poked around the debugger code to see if this is practical; it is just an
approach to consider. I haven't seen the seaside code but it
seems the weak point is the 'during' block; if it blocks other processes during
execution then that would be bad for debugging with a separate process--unless
made to allow reentrance for the debug process too. Wouter, an approach I've used to portably
implement the same kind of thing you are attempting is to use a weak key
identity dictionary as a reference collection from within application code. It
would have the same kind of debug difficulties though. Perhaps you can give an
example of why you find debugging difficult with #environmentAt:[put:] so we
aren't looking for solutions to the wrong problem. Paul Baumann From: Terry
Raymond [mailto:[hidden email]] Wouter I am not familiar with the seaside
technique, however I do know if you want to use dynamic process variables
that can be debugged, you could simply add another instance
variable to process and use a dictionary to store your variables. This
will work just fine as long as you don’t try to access it from
another process, other than a debugging tool. Terry From:
[hidden email] [mailto:[hidden email]] On Behalf Of Wouter Gazendam Hi,
|
|
|
In reply to this post by Wouter Gazendam
Hi Wouter,
Seaside includes some extensions to the debugger so
that the dynamic variables are included in the lower right
pane.
They are prefixed with '>'. All dynamic variables
that were found in the stack are included, not only WASession
instances.
Did you notice it ? Doesn't it help
?
If you had noticed it, I'm interested to hear what you
mean with "they don't like to be debugged"
Cheers,
Michel.
|
|
|
I use a subclass of WADynamicVariable for my persistence session. That way I can call everywhere in my code things like 'MyPersistedClass allDatabaseInstances' where #allDatabaseInstances somewhere uses the value of the persistence session bound to the thread.
When I'm in the debugger stepping over 'MyPersistedClass allDatabaseInstances' #allDatabaseInstances isn't able to find the persistence session. Wouter
On 6/27/07, Bany, Michel <[hidden email]> wrote:
|
|
|
In reply to this post by Terry Raymond
Terry wrote: >>I am not quite sure what you mean. ... >>If you are thinking of
performing a doit on >>“Kernel.Processor activeProcess
environmentAt: #test” >>from within the debugger, that will not work. ... >>The
debugger is...not process
faithful >>for doIts, printIts, and inspectIts. Paul Baumann
From: Terry Raymond [mailto:[hidden email]] Sent: Tuesday, June 26, 2007 8:18 PM To: Paul Baumann; 'Wouter Gazendam'; 'vwnc' Subject: RE: Thread scoped variables Importance: High Paul I am not quite sure
what you mean. When I execute the following doit, and then step
when the debugger pops up.
Kernel.Processor activeProcess environmentAt: #test put:
'here'. The debugger shows
‘here’ as the result of the #environmentAt:. If you are thinking of
performing a doit on “Kernel.Processor
activeProcess environmentAt: #test” from within the
debugger, that will not work. A simple solution to this problem would
be to add a menu command that will open an inspector on the
process being debugged. The debugger is a
process faithful debugger when executing debugger control
commands. However, it is not process faithful for doIts, printIts,
and inspectIts. The problem I am
referring to is that the window manager also uses the environment
dictionary and when the debugger steps into #environmentAt: the
debugger may deadlock. Terry From: Paul
Baumann [mailto:[hidden email]] I'm guessing that the
problem Wouter experienced with #environmentAt:[put:] is that the debugger
runs in a separate process. The debugger process doesn't return values
stored for the debugged
process; execute:
Kernel.Processor activeProcess environmentAt: #test put:
'here'. then try to find the
value stored for #test from within the debugger. There is no obvious way to
gain a reference to the process being debugged so that you can send messages to
it. The debugger process returns environment variables for
itself. Terry, are you
suggesting to modify the schema of the Process class to add a variable that the
debugger will somehow know to reference? It seems like this would fail for
the same reason; the debugger process is not the same as the process being
debugged. Perhaps you are suggesting something else, like to declare a
variable within the execution stack of the process something like
this: |
myProcess |
myProcess environmentAt: #test. That may help by
providing a process reference somewhere deep in stack, but it doesn't
really make the debugger behave as if working with the process being debugged.
That approach isn't likely to be practical even if set earlier in the same
stack. I have a debugger
implementation idea, Terry. Can you configure the environment of the new
debugger process to be a #newSubEnvironment of the #environment of the process
being debugged? The debug process would then read variables stored in the
debugged process but would not be able to update them (except through
#parentEnvironment). Sorry, I haven't poked around the debugger code to see if
this is practical; it is just an approach to
consider. I haven't seen the
seaside code but it seems the weak point is the 'during' block; if it blocks
other processes during execution then that would be bad for debugging with a
separate process--unless made to allow reentrance for the debug process
too. Wouter, an approach
I've used to portably implement the same kind of thing you are attempting is to
use a weak key identity dictionary as a reference collection from within
application code. It would have the same kind of debug difficulties though.
Perhaps you can give an example of why you find debugging difficult with
#environmentAt:[put:] so we aren't looking for solutions to the wrong
problem. Paul
Baumann From: Terry
Raymond [mailto:[hidden email]] Wouter I am not familiar with
the seaside technique, however I do know
if you want to use dynamic
process variables that can be
debugged, you could simply add
another instance variable to process and
use a dictionary to store
your variables. This will work just fine as
long as you don’t try to
access it from another process, other
than a debugging
tool. Terry From:
[hidden email] [mailto:[hidden email]] On Behalf Of Wouter Gazendam Hi,
|
|
|
Paul Some of the debugger problems are due to
its use of other system resources, i.e. dependents. As these are
identified their use can be eliminated, though not using streams
might be kind of difficult. Hopefully, some of the 7.5 changes have
reduced the occurences of these problems. However, after responding to your message
I realized that part of the doIt problem could be solved by
replacing the debug process’s suspended context with the doIt context
and then performing the doIt. Terry From: Paul Baumann
[mailto:[hidden email]] Terry wrote: >>I am not quite sure what you mean.
... >>If you are thinking of performing
a doit on >>“Kernel.Processor
activeProcess environmentAt: #test” >>from within the debugger, that
will not work. ... >>The debugger is...not process
faithful >>for doIts, printIts, and
inspectIts. Paul Baumann From: Terry
Raymond [mailto:[hidden email]] Paul I am not quite sure what you mean. When I
execute the following doit, and then step when the debugger pops
up. Kernel.Processor
activeProcess environmentAt: #test put: 'here'. The debugger shows ‘here’ as
the result of the #environmentAt:. If you are thinking of performing a doit on “Kernel.Processor activeProcess
environmentAt: #test” from within the debugger, that will not
work. A simple solution to this problem would be to add a menu
command that will open an inspector on the process being debugged. The debugger is a process faithful
debugger when executing debugger control commands. However, it is
not process faithful for doIts, printIts, and inspectIts. The problem I am referring to is that the
window manager also uses the environment dictionary and when
the debugger steps into #environmentAt: the debugger may deadlock. Terry From: Paul Baumann
[mailto:[hidden email]] I'm guessing that the problem Wouter
experienced with #environmentAt:[put:] is that the debugger runs in a separate
process. The debugger process doesn't return values stored for
the debugged process; execute: Kernel.Processor
activeProcess environmentAt: #test put: 'here'. then try to find the value stored for
#test from within the debugger. There is no obvious way to gain a reference to
the process being debugged so that you can send messages to it. The debugger
process returns environment variables for itself. Terry, are you suggesting to modify the
schema of the Process class to add a variable that the debugger will somehow
know to reference? It seems like this would fail for the same reason; the
debugger process is not the same as the process being debugged. Perhaps you are
suggesting something else, like to declare a variable within the
execution stack of the process something like this: | myProcess | myProcess
environmentAt: #test. That may help by providing a process
reference somewhere deep in stack, but it doesn't really make the debugger
behave as if working with the process being debugged. That approach isn't
likely to be practical even if set earlier in the same stack. I have a debugger implementation idea,
Terry. Can you configure the environment of the new debugger process to be a
#newSubEnvironment of the #environment of the process being debugged? The debug
process would then read variables stored in the debugged process but would not
be able to update them (except through #parentEnvironment). Sorry, I haven't
poked around the debugger code to see if this is practical; it is just an
approach to consider. I haven't seen the seaside code but it
seems the weak point is the 'during' block; if it blocks other processes during
execution then that would be bad for debugging with a separate process--unless
made to allow reentrance for the debug process too. Wouter, an approach I've used to portably
implement the same kind of thing you are attempting is to use a weak key
identity dictionary as a reference collection from within application code. It
would have the same kind of debug difficulties though. Perhaps you can give an
example of why you find debugging difficult with #environmentAt:[put:] so we
aren't looking for solutions to the wrong problem. Paul Baumann From: Terry
Raymond [mailto:[hidden email]] Wouter I am not familiar with the seaside
technique, however I do know if you want to use dynamic process variables
that can be debugged, you could simply add another instance
variable to process and use a dictionary to store your variables. This
will work just fine as long as you don’t try to access it from
another process, other than a debugging tool. Terry From:
[hidden email] [mailto:[hidden email]] On Behalf Of Wouter Gazendam Hi,
|
|
|
Terry wrote:
>> I realized that part of
>>the doIt problem
could be solved by replacing the debug process’s >>suspended context with the doIt context and then performing the doIt.
Consider
the VisualAge way of debug printing. Tools like debuggers, dumpers, and
inspectors used #debugPrintOn: that indirectly used #printOn:. That indirection
makes for a flexible way of catching/avoiding deadlocks and customizing
output for debug purposes. I know VW added that #basicPrintOn: thing several
releases ago (perhaps in response to my requests for #debugPrintOn:), but
#basicPrintOn: is not the same. The VA code didn't have deadlock avoidance. If
deadlock avoidance and (perhaps) exception handling was a primary feature of a
VW #debugPrintOn: (rather than a tool feature) then I expect it would be more
valuable.
>>Some of the debugger
problems are due to its use of other system >>resources, i.e. dependents. As these are identified their
use can >>be eliminated, though not using streams might be kind of difficult. I'm not aware of the
stream-dependent-debugger issues. I assume you are talking about file
and/or display streams that use external/OS resources. The common
techniques for dealing with restricted resources are: 1) semaphores; 2)
queues; 3) separate channels; 4) combinations of 1-3. I'd need more background
on the issue.
Cheers,
Paul Baumann
From: Terry Raymond [mailto:[hidden email]] Sent: Wednesday, June 27, 2007 3:59 PM To: Paul Baumann; 'Wouter Gazendam'; 'vwnc' Subject: RE: Thread scoped variables Importance: High Paul Some of the debugger
problems are due to its use of other system resources, i.e.
dependents. As these are identified their use can be eliminated, though
not using streams might be kind of difficult. Hopefully, some of the
7.5 changes have reduced the occurences of these
problems. However, after
responding to your message I realized that part of the doIt problem could
be solved by replacing the debug process’s suspended context with
the doIt context and then performing the doIt. Terry From: Paul
Baumann [mailto:[hidden email]] Terry
wrote: >>I am not quite
sure what you mean. ... >>If you are
thinking of performing a doit on >>“Kernel.Processor
activeProcess environmentAt: #test” >>from within the
debugger, that will not work. ... >>The debugger
is...not process faithful >>for doIts,
printIts, and inspectIts. Paul
Baumann From: Terry
Raymond [mailto:[hidden email]] Paul I am not quite sure
what you mean. When I execute the
following doit, and then step
when the debugger pops up.
Kernel.Processor activeProcess environmentAt: #test put:
'here'. The debugger shows
‘here’ as the result of the
#environmentAt:. If you are thinking of
performing a doit on “Kernel.Processor
activeProcess environmentAt: #test” from within the
debugger, that will not work. A simple
solution to this problem would
be to add a menu command that will
open an inspector on the
process being debugged. The debugger is a
process faithful debugger when
executing debugger control
commands. However, it is not process
faithful for doIts, printIts,
and inspectIts. The problem I am
referring to is that the window manager
also uses the environment
dictionary and when the debugger steps
into #environmentAt: the
debugger may deadlock. Terry From: Paul
Baumann [mailto:[hidden email]] I'm guessing that the
problem Wouter experienced with #environmentAt:[put:] is that the debugger
runs in a separate process. The debugger process doesn't return values
stored for the debugged
process; execute:
Kernel.Processor activeProcess environmentAt: #test put:
'here'. then try to find the
value stored for #test from within the debugger. There is no obvious way to
gain a reference to the process being debugged so that you can send messages to
it. The debugger process returns environment variables for
itself. Terry, are you
suggesting to modify the schema of the Process class to add a variable that the
debugger will somehow know to reference? It seems like this would fail for
the same reason; the debugger process is not the same as the process being
debugged. Perhaps you are suggesting something else, like to declare a
variable within the execution stack of the process something like
this: |
myProcess |
myProcess environmentAt: #test. That may help by
providing a process reference somewhere deep in stack, but it doesn't
really make the debugger behave as if working with the process being debugged.
That approach isn't likely to be practical even if set earlier in the same
stack. I have a debugger
implementation idea, Terry. Can you configure the environment of the new
debugger process to be a #newSubEnvironment of the #environment of the process
being debugged? The debug process would then read variables stored in the
debugged process but would not be able to update them (except through
#parentEnvironment). Sorry, I haven't poked around the debugger code to see if
this is practical; it is just an approach to
consider. I haven't seen the
seaside code but it seems the weak point is the 'during' block; if it blocks
other processes during execution then that would be bad for debugging with a
separate process--unless made to allow reentrance for the debug process
too. Wouter, an approach
I've used to portably implement the same kind of thing you are attempting is to
use a weak key identity dictionary as a reference collection from within
application code. It would have the same kind of debug difficulties though.
Perhaps you can give an example of why you find debugging difficult with
#environmentAt:[put:] so we aren't looking for solutions to the wrong
problem. Paul
Baumann From: Terry
Raymond [mailto:[hidden email]] Wouter I am not familiar with
the seaside technique, however I do know
if you want to use dynamic
process variables that can be
debugged, you could simply add
another instance variable to process and
use a dictionary to store
your variables. This will work just fine as
long as you don’t try to
access it from another process, other
than a debugging
tool. Terry From:
[hidden email] [mailto:[hidden email]] On Behalf Of Wouter Gazendam Hi,
|
|
|
In reply to this post by Paul Baumann
> ... #insteadOfWaitingDo: ...
Hmm, how about #waitOr: ? Dave Paul Baumann wrote: > Terry wrote: > >> >I am not quite sure what you mean. > > ... > >> >If you are thinking of performing a doit on > >> >“Kernel.Processor activeProcess environmentAt: #test” > >> >from within the debugger, that will not work. > > ... > >> >The debugger is...not process faithful > >> >for doIts, printIts, and inspectIts. > > > > Yes, that is what I said, demonstrated, and proposed an idea for > improving. Your suggestion for a menu command would be fine too. Wouter > wasn't clear why he was having trouble debugging so I responded to the > most likely scenario. I see now that stepping into #environmentAt: (but > not #at:) would be a way to reference the process being debugged; > neither workaround is necessary. > > > > If the true problem Wouter is facing is a debugger deadlock when > stepping into a process environment semaphore then refer to > the solutions discussed in the vwnc thread titled "insteadOfWaitingDo: > [Re: [Bug?] Global EventTable, debugger and deadlocks]" around Feb 8, > 2007. These kinds of problems are common when debugging into > semaphores--as I'm sure you are well aware. A fair amount of the > problems I'm called in to debug and work around are related to > semaphore-debug deadlocks and print code that bypasses semaphores when > it should not (not VW problems, but other 3rd party code). Stuff like > this has sometimes made the reporting of errors more harmful than the > errors themselves. It would be nice if you could make the debugger, > stack dumping, and inspector code more resilient to this kind of > problem. Preferably, the debugger is only showing information and would > show something else [immediately] instead of getting stuck. > > > > *Paul Baumann* > > > ------------------------------------------------------------------------ > *From:* Terry Raymond [mailto:[hidden email]] > *Sent:* Tuesday, June 26, 2007 8:18 PM > *To:* Paul Baumann; 'Wouter Gazendam'; 'vwnc' > *Subject:* RE: Thread scoped variables > *Importance:* High > > Paul > > > > I am not quite sure what you mean. When I execute the following > > doit, and then step when the debugger pops up. > > > > Kernel.Processor activeProcess environmentAt: #test put: 'here'. > self halt. > Kernel.Processor activeProcess environmentAt: #test > > > > The debugger shows ‘here’ as the result of the #environmentAt:. > > > > If you are thinking of performing a doit on > > “Kernel.Processor activeProcess environmentAt: #test” > > from within the debugger, that will not work. A simple solution > > to this problem would be to add a menu command that will open > > an inspector on the process being debugged. > > > > The debugger is a process faithful debugger when executing > > debugger control commands. However, it is not process faithful > > for doIts, printIts, and inspectIts. > > > > The problem I am referring to is that the window manager also > > uses the environment dictionary and when the debugger steps into > > #environmentAt: the debugger may deadlock. > > > > Terry > > =========================================================== > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== > > ------------------------------------------------------------------------ > > *From:* Paul Baumann [mailto:[hidden email]] > *Sent:* Tuesday, June 26, 2007 7:50 PM > *To:* Terry Raymond; Wouter Gazendam; vwnc > *Subject:* RE: Thread scoped variables > > > > I'm guessing that the problem Wouter experienced with > #environmentAt:[put:] is that the debugger runs in a separate > process. The debugger process doesn't return values stored for > the debugged process; execute: > > > > Kernel.Processor activeProcess environmentAt: #test put: 'here'. > self halt. > Kernel.Processor activeProcess environmentAt: #test > > > > then try to find the value stored for #test from within the debugger. > There is no obvious way to gain a reference to the process being > debugged so that you can send messages to it. The debugger process > returns environment variables for itself. > > > > Terry, are you suggesting to modify the schema of the Process class to > add a variable that the debugger will somehow know to reference? It > seems like this would fail for the same reason; the debugger process is > not the same as the process being debugged. Perhaps you are suggesting > something else, like to declare a variable within the execution stack of > the process something like this: > > > > | myProcess | > (myProcess := Kernel.Processor activeProcess) environmentAt: #test > put: 'here'. > self halt. > Kernel.Processor activeProcess environmentAt: #test. > > myProcess environmentAt: #test. > > > > That may help by providing a process reference somewhere deep in stack, > but it doesn't really make the debugger behave as if working with the > process being debugged. That approach isn't likely to be practical even > if set earlier in the same stack. > > > > I have a debugger implementation idea, Terry. Can you configure the > environment of the new debugger process to be a #newSubEnvironment of > the #environment of the process being debugged? The debug process would > then read variables stored in the debugged process but would not be able > to update them (except through #parentEnvironment). Sorry, I haven't > poked around the debugger code to see if this is practical; it is just > an approach to consider. > > > > I haven't seen the seaside code but it seems the weak point is the > 'during' block; if it blocks other processes during execution then that > would be bad for debugging with a separate process--unless made to allow > reentrance for the debug process too. > > > > Wouter, an approach I've used to portably implement the same kind of > thing you are attempting is to use a weak key identity dictionary as a > reference collection from within application code. It would have the > same kind of debug difficulties though. Perhaps you can give an example > of why you find debugging difficult with #environmentAt:[put:] so we > aren't looking for solutions to the wrong problem. > > > > **Paul Baumann** > > > > > > ------------------------------------------------------------------------ > > *From:* Terry Raymond [mailto:[hidden email]] > *Sent:* Tuesday, June 26, 2007 9:04 AM > *To:* 'Wouter Gazendam'; 'vwnc' > *Subject:* RE: Thread scoped variables > > Wouter > > > > I am not familiar with the seaside technique, however I do know if > > you want to use dynamic process variables that can be debugged, > > you could simply add another instance variable to process and use > > a dictionary to store your variables. This will work just fine as long > > as you don’t try to access it from another process, other than > > a debugging tool. > > > > Terry > > =========================================================== > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== > > ------------------------------------------------------------------------ > > *From:* [hidden email] [mailto:[hidden email]] *On > Behalf Of *Wouter Gazendam > *Sent:* Tuesday, June 26, 2007 8:49 AM > *To:* vwnc > *Subject:* Thread scoped variables > > > > Hi, > > I've seen two patterns in use in visualworks for having a variable bound > to a certain thread of execution. The first is using 'Processor > activeProcess environmentAt:[put:]', the second one is Seaside's > 'WADynamicVariable use:during:'. Both seem to have problems, in that > they don't like to be debugged. > > - What do you use out there? > - Are there ways to make it more debugging friendly? > > Tnx, > > Wouter > > > > > > > > ------------------------------------------------------------------------ > > This message may contain confidential information and is intended > for specific recipients unless explicitly noted otherwise. If you > have reason to believe you are not an intended recipient of this > message, please delete it and notify the sender. This message may > not represent the opinion of IntercontinentalExchange, Inc. (ICE), > its subsidiaries or affiliates, and does not constitute a contract > or guarantee. Unencrypted electronic mail is not secure and the > recipient of this message is expected to provide safeguards from > viruses and pursue alternate means of communication where privacy or > a binding message is desired. > > > > > > > > ------------------------------------------------------------------------ > > This message may contain confidential information and is intended > for specific recipients unless explicitly noted otherwise. If you > have reason to believe you are not an intended recipient of this > message, please delete it and notify the sender. This message may > not represent the opinion of IntercontinentalExchange, Inc. (ICE), > its subsidiaries or affiliates, and does not constitute a contract > or guarantee. Unencrypted electronic mail is not secure and the > recipient of this message is expected to provide safeguards from > viruses and pursue alternate means of communication where privacy or > a binding message is desired. > |
|
|
Oops, I meant #proceedOr: ...
A month is way too long to stay at a hotel ... Dave Dave Stevenson wrote: > > ... #insteadOfWaitingDo: ... > > Hmm, how about #waitOr: ? > > Dave > > Paul Baumann wrote: >> Terry wrote: >> >>> >I am not quite sure what you mean. >> >> ... >> >>> >If you are thinking of performing a doit on >> >>> >“Kernel.Processor activeProcess environmentAt: #test” >> >>> >from within the debugger, that will not work. >> >> ... >> >>> >The debugger is...not process faithful >> >>> >for doIts, printIts, and inspectIts. >> >> >> >> Yes, that is what I said, demonstrated, and proposed an idea for >> improving. Your suggestion for a menu command would be fine too. >> Wouter wasn't clear why he was having trouble debugging so I responded >> to the most likely scenario. I see now that stepping into >> #environmentAt: (but not #at:) would be a way to reference the process >> being debugged; neither workaround is necessary. >> >> >> >> If the true problem Wouter is facing is a debugger deadlock when >> stepping into a process environment semaphore then refer to the >> solutions discussed in the vwnc thread titled "insteadOfWaitingDo: >> [Re: [Bug?] Global EventTable, debugger and deadlocks]" around Feb 8, >> 2007. These kinds of problems are common when debugging into >> semaphores--as I'm sure you are well aware. A fair amount of the >> problems I'm called in to debug and work around are related to >> semaphore-debug deadlocks and print code that bypasses semaphores when >> it should not (not VW problems, but other 3rd party code). Stuff like >> this has sometimes made the reporting of errors more harmful than the >> errors themselves. It would be nice if you could make the debugger, >> stack dumping, and inspector code more resilient to this kind of >> problem. Preferably, the debugger is only showing information and >> would show something else [immediately] instead of getting stuck. >> >> >> >> *Paul Baumann* >> >> ------------------------------------------------------------------------ >> *From:* Terry Raymond [mailto:[hidden email]] >> *Sent:* Tuesday, June 26, 2007 8:18 PM >> *To:* Paul Baumann; 'Wouter Gazendam'; 'vwnc' >> *Subject:* RE: Thread scoped variables >> *Importance:* High >> >> Paul >> >> >> >> I am not quite sure what you mean. When I execute the following >> >> doit, and then step when the debugger pops up. >> >> >> >> Kernel.Processor activeProcess environmentAt: #test put: 'here'. >> self halt. >> Kernel.Processor activeProcess environmentAt: #test >> >> >> >> The debugger shows ‘here’ as the result of the #environmentAt:. >> >> >> >> If you are thinking of performing a doit on >> >> “Kernel.Processor activeProcess environmentAt: #test” >> >> from within the debugger, that will not work. A simple solution >> >> to this problem would be to add a menu command that will open >> >> an inspector on the process being debugged. >> >> >> >> The debugger is a process faithful debugger when executing >> >> debugger control commands. However, it is not process faithful >> >> for doIts, printIts, and inspectIts. >> >> >> >> The problem I am referring to is that the window manager also >> >> uses the environment dictionary and when the debugger steps into >> >> #environmentAt: the debugger may deadlock. >> >> >> >> Terry >> >> =========================================================== >> Terry Raymond >> Crafted Smalltalk >> 80 Lazywood Ln. >> Tiverton, RI 02878 >> (401) 624-4517 [hidden email] >> <http://www.craftedsmalltalk.com> >> =========================================================== >> >> ------------------------------------------------------------------------ >> >> *From:* Paul Baumann [mailto:[hidden email]] >> *Sent:* Tuesday, June 26, 2007 7:50 PM >> *To:* Terry Raymond; Wouter Gazendam; vwnc >> *Subject:* RE: Thread scoped variables >> >> >> >> I'm guessing that the problem Wouter experienced with >> #environmentAt:[put:] is that the debugger runs in a separate process. >> The debugger process doesn't return values stored for the debugged >> process; execute: >> >> >> >> Kernel.Processor activeProcess environmentAt: #test put: 'here'. >> self halt. >> Kernel.Processor activeProcess environmentAt: #test >> >> >> >> then try to find the value stored for #test from within the debugger. >> There is no obvious way to gain a reference to the process being >> debugged so that you can send messages to it. The debugger process >> returns environment variables for itself. >> >> >> >> Terry, are you suggesting to modify the schema of the Process class to >> add a variable that the debugger will somehow know to reference? It >> seems like this would fail for the same reason; the debugger process >> is not the same as the process being debugged. Perhaps you are >> suggesting something else, like to declare a variable within the >> execution stack of the process something like this: >> >> >> >> | myProcess | >> (myProcess := Kernel.Processor activeProcess) environmentAt: #test >> put: 'here'. >> self halt. >> Kernel.Processor activeProcess environmentAt: #test. >> >> myProcess environmentAt: #test. >> >> >> >> That may help by providing a process reference somewhere deep in >> stack, but it doesn't really make the debugger behave as if working >> with the process being debugged. That approach isn't likely to be >> practical even if set earlier in the same stack. >> >> >> >> I have a debugger implementation idea, Terry. Can you configure the >> environment of the new debugger process to be a #newSubEnvironment of >> the #environment of the process being debugged? The debug process >> would then read variables stored in the debugged process but would not >> be able to update them (except through #parentEnvironment). Sorry, I >> haven't poked around the debugger code to see if this is practical; it >> is just an approach to consider. >> >> >> >> I haven't seen the seaside code but it seems the weak point is the >> 'during' block; if it blocks other processes during execution then >> that would be bad for debugging with a separate process--unless made >> to allow reentrance for the debug process too. >> >> >> >> Wouter, an approach I've used to portably implement the same kind of >> thing you are attempting is to use a weak key identity dictionary as a >> reference collection from within application code. It would have the >> same kind of debug difficulties though. Perhaps you can give an >> example of why you find debugging difficult with #environmentAt:[put:] >> so we aren't looking for solutions to the wrong problem. >> >> >> >> **Paul Baumann** >> >> >> >> >> ------------------------------------------------------------------------ >> >> *From:* Terry Raymond [mailto:[hidden email]] >> *Sent:* Tuesday, June 26, 2007 9:04 AM >> *To:* 'Wouter Gazendam'; 'vwnc' >> *Subject:* RE: Thread scoped variables >> >> Wouter >> >> >> >> I am not familiar with the seaside technique, however I do know if >> >> you want to use dynamic process variables that can be debugged, >> >> you could simply add another instance variable to process and use >> >> a dictionary to store your variables. This will work just fine as long >> >> as you don’t try to access it from another process, other than >> >> a debugging tool. >> >> >> >> Terry >> >> =========================================================== >> Terry Raymond >> Crafted Smalltalk >> 80 Lazywood Ln. >> Tiverton, RI 02878 >> (401) 624-4517 [hidden email] >> <http://www.craftedsmalltalk.com> >> =========================================================== >> >> ------------------------------------------------------------------------ >> >> *From:* [hidden email] [mailto:[hidden email]] >> *On Behalf Of *Wouter Gazendam >> *Sent:* Tuesday, June 26, 2007 8:49 AM >> *To:* vwnc >> *Subject:* Thread scoped variables >> >> >> >> Hi, >> >> I've seen two patterns in use in visualworks for having a variable >> bound to a certain thread of execution. The first is using 'Processor >> activeProcess environmentAt:[put:]', the second one is Seaside's >> 'WADynamicVariable use:during:'. Both seem to have problems, in that >> they don't like to be debugged. >> >> - What do you use out there? >> - Are there ways to make it more debugging friendly? >> >> Tnx, >> >> Wouter >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> This message may contain confidential information and is intended >> for specific recipients unless explicitly noted otherwise. If you >> have reason to believe you are not an intended recipient of this >> message, please delete it and notify the sender. This message may >> not represent the opinion of IntercontinentalExchange, Inc. (ICE), >> its subsidiaries or affiliates, and does not constitute a contract >> or guarantee. Unencrypted electronic mail is not secure and the >> recipient of this message is expected to provide safeguards from >> viruses and pursue alternate means of communication where privacy or >> a binding message is desired. >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> This message may contain confidential information and is intended >> for specific recipients unless explicitly noted otherwise. If you >> have reason to believe you are not an intended recipient of this >> message, please delete it and notify the sender. This message may >> not represent the opinion of IntercontinentalExchange, Inc. (ICE), >> its subsidiaries or affiliates, and does not constitute a contract >> or guarantee. Unencrypted electronic mail is not secure and the >> recipient of this message is expected to provide safeguards from >> viruses and pursue alternate means of communication where privacy or >> a binding message is desired. >> > |
| Free forum by Nabble | Edit this page |