On Thu, May 7, 2015 at 9:09 PM, Alain Rastoul <alf.mmm....@gmail.com> wrote:
> Le 05/05/2015 14:35, Ben Coman a écrit :
>
>> Not sure if this is related, but if you put a haltOnce at the top of
>> SpecDebugger>>updateReceiverInspectorFromContext:
>> then step down until the 'receiver' temporary variable is set,
>> then inspect 'receiver', the system hangs.
>> cheers -ben
>>
>>
>> After digging into it, the cause of the hang is now obvious, but the
> simplest solution makes me perplex
> and does not cover other cases (ProcessLocalVariables, see below).
>
> The problem comes from the display of the object in the lower pane of the
> debugger
> that locks itself because the monitor is owned by the debugged process.
> (the inspector ends up in a call to xxx>>printOn: aStream to display the
> object
> and SharedQueue>>printOn: aStream starts with a critical block on the
> monitor).
> So we could be hanged in various ways : clicking on the debugger stack on
> the Sharedqueue context,
> opening an inspector on the Sharedqueue etc).
> A simple solution is to evaluate the printOn: in the context of the owner
> process
> in SharedQueue (tested and works), but it is specific to SharedQueue.
>
>
Does the #printOn: really need a monitor? What is it protecting?
* not the stream, that is passed in as a parameter from a single thread
* not the class name, that is handled normally
* items size does "^ lastIndex - firstIndex + 1" in OrderedCollection,
which presumably will be inlined and not interruptible, and even if it
could be interrupted part way through the calculation to become
inconsistent, the value is only printed, so do we really care?
For reference...
SharedQueue>>printOn: aStream
monitor critical: [
aStream
nextPutAll: self class name;
nextPutAll: ' with ';
print: items size;
nextPutAll: ' items' ].
> When an inspector ask an object to print itself, it does not take into
> account the "effective/owner process " part of the object.
>
> For example for ProcessLocalVariable (and descendants) it does not work:
> | process variable |
> process := [ variable := ProcessLocalVariable value: 'hello world' ]
> forkAt: Processor userInterruptPriority .
variable value => evaluates to nil
>
> this makes it difficult (impossible ?) to inspect/debug - a workaround
> would be to track the effective process near the host in the inspector (in
> AbstractEyeElement?) but it could be tricky and I do not know implications
> here.
>
>
I am not clear on the semantics we want debugging ProcessLocalVariable,
however if without forking I do...
variable := ProcessLocalVariable value: 'hello world'
then inspecting /variable/ shows me only...
self: a ProcessLocalVariable
index: 6
And there is no change when forking...
process := [
variable := ProcessLocalVariable value: 'hello world'.
variable inspect.
] fork.
Also, the following works as expected with respect to the /result/ variable.
| process variable result |
process := [
variable := ProcessLocalVariable value: 'hello world'.
self halt.
result := variable value.
] fork.
So as ProcessLocalVariable is currently displayed in the debugger there
seems no problem (?) for what the debugger displays.
cheers -ben
| process variable result |
process := [
variable := ProcessLocalVariable value: 'hello world'.
self halt.
result := variable value.
] fork.
