#value sent by cCall?

Hi all,

In which circumstances might a cCall, registered as follows,
invoke
#value on its argument? It happens only in a particular
circumstance
(which I'm still pinning down, but seems related to global
garbage
collection), which leads me to suspect it's not supposed to
happen *at all*.

sdlFlip: aCobject0
    "I set up a flip and return on hardware that
supports
    double-buffering, or perform a SDL_UpdateRect on
hardware that
    doesn't. My C function call prototype:

    extern DECLSPEC int SDLCALL SDL_Flip(SDL_Surface
*screen);"
    <cCall: 'SDL_Flip' returning: #int
        args: #( #cObject )>

Regards,
  Tony
-- 
 [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
 []  [] http://www.lshift.net/ |
Email: tonyglshift.net


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> In which circumstances might a cCall, registered as
follows, invoke
> #value on its argument? It happens only in a particular
circumstance
> (which I'm still pinning down, but seems related to
global garbage
> collection), which leads me to suspect it's not
supposed to happen *at all*.

Never.  In fact it took me a while to understand what you
meant.  

>     <cCall: 'SDL_Flip' returning: #int
>         args: #( #cObject )>

The code is compiled as

^(##(CFunctionDescriptor for: 'SDL_Flip' returning: #int
	args: #( #cObject ))
		callInto: ValueHolder now) value

Where "descr callInto: ValueHolder now" is
supposed to return its argument.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
> The code is compiled as
> ^(##(CFunctionDescriptor for: 'SDL_Flip' returning:
#int
>     args: #( #cObject ))
>         callInto: ValueHolder now) value
> Where "descr callInto: ValueHolder now" is
supposed to return its argument.

Excellent, thanks! In that case, what I'm seeing is that
#value is being
sent to the cObject passed in (the SDL_Surface)
occasionally, rather
than (presumably) the ValueHolder.

I thought it might have been related to global GC, but I'm
now thinking
it's something to do with #terminate instead. The failing
call is
happening during ObjectMemory quit, from a Process which has
had the new
#terminateOnQuit called on it.

... and sure enough, calling #terminate directly on the
process
concerned triggers the problem *most* (but not all) times
it's called.

I'm guessing terminate is quite an abrupt way of
interrupting a process?
If so, is there something less drastic that could be done
instead?

Regards,
  Tony
-- 
 [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
 []  [] http://www.lshift.net/ |
Email: tonyglshift.net


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Excellent, thanks! In that case, what I'm seeing is
that #value is being
> sent to the cObject passed in (the SDL_Surface)
occasionally, rather
> than (presumably) the ValueHolder.

I see.

> I'm guessing terminate is quite an abrupt way of
interrupting a process?
> If so, is there something less drastic that could be
done instead?

No, terminate is not abrupt at all.  It works by raising a
signal that 
does its way up to this signal handler:

      [...
      "Invokes the block passed to #fork."
      aBlockClosure value]
               on: SystemExceptions.ProcessBeingTerminated
               do: [:sig | sig return]]

I think it's a bug in #queueInterrupt: or something like
that.

Can you make a self-contained testcase (one that fails
"most of the 
time" at least)?

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
> No, terminate is not abrupt at all.

That's good to know 

> I think it's a bug in #queueInterrupt: or something
like that.
> Can you make a self-contained testcase (one that fails
"most of the
> time" at least)?

I'll try!

Regards,
  Tony
-- 
 [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
 []  [] http://www.lshift.net/ |
Email: tonyglshift.net


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
> No, terminate is not abrupt at all.  It works by
raising a signal that
> does its way up to this signal handler:

Is it permitted to terminate the "root"
CallinProcess?

It seems that it is already dead! which could be the cause
of the fault
I was seeing? I also have a test case that does Something
Weird, but I'm
not sure whether it's a problem with my code or with the
system. I'll
attach it in a separate message.

~$ gst
GNU Smalltalk ready

st> Processor activeProcess.
CallinProcess('call-in process' at userSchedulingPriority,
terminated)
st> Processor activeProcess terminate.
CallinProcess('call-in process' at userSchedulingPriority,
terminated)
st> Processor activeProcess terminate.
CallinProcess('call-in process' at userSchedulingPriority,
terminated)
st>


Tony
-- 
 [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
 []  [] http://www.lshift.net/ |
Email: tonyglshift.net


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk