Re: #1638: Signal handling and parameters

[Chicken Trac]

#1638: Signal handling and parameters
-------------------------------------+-------------------------------------
            Reporter:  Mario         |      Owner:  (none)
  Domenech Goulart                   |
                Type:  defect        |     Status:  new
            Priority:  major         |  Milestone:  5.3
           Component:  unknown       |    Version:  5.1.0
          Resolution:                |   Keywords:  signals, parameters
Estimated difficulty:                |
-------------------------------------+-------------------------------------

Comment (by Sebastien Marie):

 if I correctly traced the problem, it is located in scheduler.

 {{{##sys#update-thread-state-buffer}}} and {{{##sys#restore-thread-state-
 buffer}}} are used to save/restore elements, and among others {{{##sys
 #current-parameter-vector}}} (which keep track of parameters changes).

 with the current code of the scheduler, after an interruption is
 proceeded, the thread-state-buffer is overrided (without saving) by
 previous state, resulting changes lost.

 the code exposes the problem because when {{{{(param 42)}}} is called the
 vector is resized. so it is the same vector which is used (even if value
 inside the vector changed). When {{{{(param 42)}}} is not called, when the
 interruption-code call {{{{(param 4)}}} it trigger a resize, and so
 {{{##sys#current-parameter-vector}}} points to a new vector with new
 values, and once the primodial thread is rescheduled, it first calls
 {{{##sys#restore-thread-state-buffer}}} and {{{##sys#current-parameter-
 vector}}} is overrided by the old vector (with old values).

 With a modified scheduler.scm, I have the following trace:
 {{{
 switching to #<thread: primordial>
 ##sys#restore-thread-state-buffer: override global with thread data:
 global=29 thread=29
 42
 #<thread: primordial> blocks for timeout 4652.0
 ==================== scheduling, current: #<thread: primordial>, ready: ()
 ##sys#update-thread-state-buffer: override thread data with global:
 global=29 thread=29
 timeout: #<thread: primordial> -> 4652.0 (now: 3652)
 reloading
   old value 42
   new value 4
 primordial thread forced due to interrupt
 unblocking: #<thread: primordial>
 switching to #<thread: primordial>
 ##sys#restore-thread-state-buffer: override global with thread data:
 global=31 thread=29
 42
 #
 }}}

 it shows that after the interrupt code, when the primodial thread is
 rescheduler, the global vector (with size 31) is overrided by the thread-
 state-buffer data (a vector with size 29).

 the attached diff calls {{{##sys#update-thread-state-buffer}}} before
 primordial thread is rescheduled. but as I am unfamiliar with scheduler
 internal, I am unsure it is properly done.

-- 
Ticket URL: <https://bugs.call-cc.org/ticket/1638#comment:3>
CHICKEN Scheme <https://www.call-cc.org/>
CHICKEN Scheme is a compiler for the Scheme programming language.