Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0003292 [Croquet] Hedgehog major always 03-11-06 00:15 03-15-06 23:07
Reporter schwa View Status public  
Assigned To andreas
Priority normal Resolution fixed  
Status closed  
Summary 0003292: Island 'exports' filling up with TFarRefs to BlockContexts
Description The problematic code is the following line in CroquetHarness>>findViewpointByPostcard: (in this case being called from TPortal>>render:depth:)
    rval := island send:[ :isl | isl at: pc viewpointName ifAbsent:[nil]].

The [nil] block get wrapped up in a TFarRef which is stored in the 'exports' map of the TIsland sending the message. And there it stays.... FOREVER!!!! (sorry, it's Friday)

I'm considering a few options:
1. make a variant of Island>>at: that returns nil if the object isn't present
2. explicitly wrap the [nil] in a TFarRef
3. change TIsland>>asFarRef: to check if the object is a block, and if so, don't put it in 'exports'. (this seems too bletcherous)
4. Have #syncSend:withArguments: use a subclass of IslandArgumentCopier that creates proxies via #asUnexportedFarRef: (which is like #asFarRef:, except it doesn't put the result in 'exports'

1. and 2. don't provide a general solution to this class of problems, but they're much less intrusive, so I'll try one of them. Actually, even 2 is problematic, since it is only when adding to the FarRefMap that #privateValue:island: is called on the TFarRef (my understanding is that #privateValue:island: should be called VERY sparingly).

Oh! I missed the easiest solution of all:
5. Replace [nil] with nil
Additional Information
Attached Files  FixExcessFarRefGeneration.1.cs.gz [^] (543 bytes) 03-11-06 00:18

- Relationships

SYSTEM WARNING: Creating default object from empty value

related to 0003252new  System freezes up when left standing 
related to 0003298confirmed  futureSend futures never go away 
child of 0003297confirmed  island export and nameMap tables filling up 

- Notes
(0004429 - 82 - 82 - 82 - 82 - 82 - 82)
schwa
03-11-06 00:18

Attached changeset (FixExcessFarRefGeneration.1.cs.gz) appears to fix the problem.
 
(0004457 - 6 - 6 - 6 - 6 - 6 - 6)
andreas
03-14-06 02:16

Fixed.
 
(0004507 - 18 - 18 - 18 - 18 - 18 - 18)
andreas
03-15-06 23:07

Included in beta3.
 

- Issue History
Date Modified Username Field Change
03-11-06 00:15 schwa New Issue
03-11-06 00:18 schwa Note Added: 0004429
03-11-06 00:18 schwa File Added: FixExcessFarRefGeneration.1.cs.gz
03-13-06 02:58 howardstearns Relationship added related to 0003252
03-13-06 19:01 howardstearns Relationship added child of 0003297
03-13-06 19:11 howardstearns Relationship added related to 0003298
03-14-06 02:16 andreas Status new => resolved
03-14-06 02:16 andreas Resolution open => fixed
03-14-06 02:16 andreas Assigned To  => andreas
03-14-06 02:16 andreas Note Added: 0004457
03-15-06 23:07 andreas Status resolved => closed
03-15-06 23:07 andreas Note Added: 0004507


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
60 total queries executed.
41 unique queries executed.
Powered by Mantis Bugtracker