[Vm-dev] Re: fun with callbackEnter
Andreas Raab
andreas.raab at gmx.de
Tue Nov 10 19:37:11 UTC 2009
Oh. Interesting observation. Sounds right to me. Guess we'll have to add
a checkForInterrupts() to callbackEnter. BTW, this strongly resonates
with what I was writing about the event driven VM. In that scheme
"callbackEnter" would be a straightforward call to interpret().
Cheers,
- Andreas
John M McIntosh wrote:
> Since we are talking about events, this is an error thrown by a iphone
> squeak vm setup as a single pthread.
>
> What happens is ioGetNextEvent is called which calls ioProcessEvents
> which on a special version of the iphone vm
> calls [NSRunLoop currentRunLoop] to run for N milliseconds.
>
> When the run loop runs it ends up sending a message to an Objective-C
> SqueakProxy instance which then signals
> a squeak semaphore to wake up the VM. In this specialized VM it does
>
> interpreterProxy->signalSemaphoreWithIndex(sem);
> interpreterProxy->callbackEnter(&callbackid);
>
> However I *think* the problem here is that although we signal the
> semaphore then issue the forceInterruptCheck
> in callbackEnter: this does not actually alter the runnable processes
> list since that work is only done when
> checkForInterrrupts() is run. Thus in this case the only process
> running is the idleProcess, and it's sleeping
> but we are attempting to wake a squeakProxy process waiting on the
> semaphore we did signal, but
> as you see oops nada runnable, so die.
>
>
>
> 2009-11-10 12:59:36.214 x[13886:207] forwardInvocation: <NSInvocation:
> 0x1368370>
> 2009-11-10 12:59:36.215 x[13886:207] currentThread: <NSThread:
> 0x1105e90>{name = (null), num = 1}
> 2009-11-10 12:59:36.219 x[13886:207] inside lock 0
> 2009-11-10 12:59:36.220 x[13886:207] signalling squeak
>
> scheduler could not find a runnable process
>
> 548435824 >idleProcess
> 548435732 >startUp
> 548291060 BlockClosure>newProcess
>
>
>
> callbackEnter: callbackID
> "Re-enter the interpreter for executing a callback"
> | result activeProc |
> self export: true.
> self var: #callbackID declareC: 'sqInt *callbackID'.
>
> "For now, do not allow a callback unless we're in a primitiveResponse"
> primitiveIndex = 0 ifTrue:[^false].
>
> "Check if we've exceeded the callback depth"
> jmpDepth >= jmpMax ifTrue:[^false].
> jmpDepth := jmpDepth + 1.
>
> "Suspend the currently active process"
> activeProc := self fetchPointer: ActiveProcessIndex
> ofObject: self schedulerPointer.
> suspendedCallbacks at: jmpDepth put: activeProc.
> "We need to preserve newMethod explicitly since it is not activated yet
> and therefore no context has been created for it. If the caller
> primitive
> for any reason decides to fail we need to make sure we execute the
> correct
> method and not the one 'last used' in the call back"
> suspendedMethods at: jmpDepth put: newMethod.
> self transferTo: self wakeHighestPriority.
>
> "Typically, invoking the callback means that some semaphore has been
> signaled to indicate the callback. Force an interrupt check right
> away."
> self forceInterruptCheck.
>
> result := self setjmp: (jmpBuf at: jmpDepth).
> result == 0 ifTrue:["Fill in callbackID"
> callbackID at: 0 put: jmpDepth.
> "This is ugly but the inliner treats interpret() in very special
> and strange ways and calling any kind of 'self interpret' either
> directly or even via cCode:inSmalltalk: will cause this entire method to
> vanish."
> self cCode: 'interpret()'.
> ].
>
> "Transfer back to the previous process so that caller can push result"
> activeProc := self fetchPointer: ActiveProcessIndex
> ofObject: self schedulerPointer.
> self putToSleep: activeProc.
> activeProc := suspendedCallbacks at: jmpDepth.
> newMethod := suspendedMethods at: jmpDepth. "see comment above"
> self transferTo: activeProc.
> jmpDepth := jmpDepth-1.
> ^true
>
>
>
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com> Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
More information about the Vm-dev
mailing list