#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: [hidden email]


_______________________________________________
help-smalltalk mailing list
[hidden email]
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
[hidden email]
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: [hidden email]


_______________________________________________
help-smalltalk mailing list
[hidden email]
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
[hidden email]
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: [hidden email]


_______________________________________________
help-smalltalk mailing list
[hidden email]
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: [hidden email]


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk