duktape/bugs/issue-a4d68fbf811b8b4f65200662393f3141dfe4c243.yaml

--- !ditz.rubyforge.org,2008-03-06/issue 
title: move longjmp state tracking from duk_heap to duk_hthread to relax threading requirements
desc: |-
  Scenario:
  
  * Multiple native threads are executing with the same Duktape heap, but
    never run at the same time (prevented using a mutex).
  
  * A Duktape/C API provides a time consuming operation (network access
    for instance).  It gathers whatever paramters it needs with Duktape
    API, releases the mutex, and performs a blocking native operation.
  
  * Meanwhile, other native threads waiting for the "Duktape lock" can
    now execute.  In particular, other Duktape threads can execute while
    one Duktape thread is blocked.
  
  One thing which prevents this from working now is the heap level tracking
  of longjmp state.  When the initial thread resumes, the heap level longjmp
  state may be incorrect and won't be restored until the Duktape/C function
  (which originally released the mutex) returns.  Errors thrown in the meanwhile
  will be handled incorrectly.
  
  If longjmp tracking was moved into duk_hthread, this situation would be
  avoided and the original scenario should most likely work.  The change is
  quite trivial except that return/throw values going across a coroutine
  boundary need a copying of ljstate instead of just resuming longjmp
  propagation in another thread.  
type: :task
component: duk
release: v0.12
reporter: Sami Vaarala <sami.vaarala@iki.fi>
status: :unstarted
disposition: 
creation_time: 2014-06-01 13:09:47.936488 Z
references: []

id: a4d68fbf811b8b4f65200662393f3141dfe4c243
log_events: 
- - 2014-06-01 13:09:48.481470 Z
  - Sami Vaarala <sami.vaarala@iki.fi>
  - created
  - ""
- - 2014-07-10 12:43:21.763955 Z
  - Sami Vaarala <sami.vaarala@iki.fi>
  - assigned to release v0.12 from v0.11
  - ""