My bad; I meant the InputEventFetcher, the effect is the same. Cheers, Henry
On Feb 13, 2012, at 2:41 PM, Igor Stasenko wrote: > On 13 February 2012 12:55, Henrik Johansen <henrik.s.johan...@veloxit.no> > wrote: >> >> On Feb 10, 2012, at 6:42 PM, Ben Coman wrote: >> >>> While I was working towards implementing >>> DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder >>> I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> >>> and then stepped down to: Cursor write show >>> at which point the debugger hung the image. >>> >>> Now I guess theres an equal chance this is not really an issue as something >>> "special" might be happening here straddling the save point. Just thought >>> I would report it for review. >>> >>> To reproduce on non-Windows you could probably set preferencesFolder & >>> preferencesGeneralFolder on your platform to self shouldBeImplemented and >>> proceed from the debugger that comes up. >>> >>> SmalltalkImage>>snapshot: save andQuit: quit >>> | snapshotResult resuming startupErrors | >>> Object flushDependents. >>> Object flushEvents. >>> self addSnapshotRecord: save andQuit: quit. >>> self processShutDownList: quit. >>> Cursor write show. <--------Image Hangs Here after a <Restart> of the >>> method while debugging following a resume.. >>> >>> cheers, -ben >> >> IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that >> would indeed lead to a non-responsive image at that point. (In the sense >> that the thing that processes input is no longer there) >> > > Well, its #shutDown method is empty. > But still, i think you have right insight. > > Because there is enough of Delay>>shutDown to stop everything, because > most stuff using delays , including UI process. > ---- > shutDown > "Suspend the active delay, if any, before snapshotting. It will be > reactived when the snapshot is resumed." > "Details: This prevents a timer interrupt from waking up the active > delay in the midst snapshoting, since the active delay will be > restarted when resuming the snapshot and we don't want to process the > delay twice." > > >> Cheers, >> Henry > > > > -- > Best regards, > Igor Stasenko. >
