[Pharo-dev] InputEventFetcher update

Guillermo Polito guillermopolito at gmail.com
Mon Nov 16 10:42:49 EST 2015


You mean how it is filled? 

Check

InputEventSensor>>installEventSensorFramework: fetcherClass

It’s ugly but I think it’s there…

newSensor registerIn: InputEventFetcher default.
UserInterruptHandler new registerIn: InputEventFetcher default.


> On 16 nov 2015, at 4:37 p.m., Christophe Demarey <Christophe.Demarey at inria.fr> wrote:
> 
> 
> Le 16 nov. 2015 à 16:15, Guillermo Polito a écrit :
> 
>> Tricky question :)
>> 
>> In theory, just doing #startUp should be enough.
> 
> for the snapshot:andQuit:, yes.
> But I'm also taking information for the bootstrap. It is good to know how to initialize the system ;)
> 
>> But! Digging a bit you see that this code depends on the ExternalSemaphoreTable which uses an array of semaphores in the special objects array.
>> 
>> unprotectedExternalObjects
>> 	^Smalltalk specialObjectsArray at: 39
>> 
>> So, before being able to work, the array at index 39 should be initialized. Which in theory can be done with
>> 
>> ExternalSemaphoreTable>>clearExternalObjects
>> 	"Clear the array of objects that have been registered for use in non-Smalltalk code."
>> 	"Only lock additions, removals executing in parallel would have little effect on the resulting array"
>> 
>> 	ProtectAdd critical: [
>> 		self unprotectedExternalObjects: Array new].
>> 
> 
> When I run 
> 	InputEventFetcher 
> 		shutDown;
> 		startUp 
> It works as expected.
> 
> It looks like the problem is there if you try to install a new instance of InputEventFetcher.
> I do not get how eventHandlers inst. var is set in this case. fetcherProcess inst. var is initialized through #installEventLoop and inputSemaphore through #StartUp.
> Maybe it is the problem.





More information about the Pharo-dev mailing list