[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-hackers] semantics of thread-suspend! and thread-resume!

From: Jörg F . Wittenberger
Subject: [Chicken-hackers] semantics of thread-suspend! and thread-resume!
Date: 19 Dec 2018 20:09:35 +0100


thread-suspend! and thread-resume! are extensions to srfi-18 provided
by the srfi-18 unit respectively the srfi-18 egg.

A warning in the source hints to the issue at hand:

   ;XXX what if thread is ready or blocked?

The semantics are weekly defined and it easy to create pathological
test cases like the one attached.

How should we handle this?  Currently I see two paths and two options:


1. Keep 'suspended as a possible thread state.

  thread-suspend! would have to be restricted to only suspend threads
  in 'ready or 'running state.


  a) Error out on other states.  This might possibly break existing
  code.  But it will catch errors early.

  b) Ignore other states.  This might incur a nightmare catching bugs
  silently ignored.

2. Make thread-suspend! and thread-resume! in-/decrement the priority
  of the subject thread starting at zero.  Rules of the game:

  I.  Any thread with a negative priority is not eligible to run.
  II. Future/alternative schedulers might schedule threads with a
      higher priority value first.  For now anything >= 0 is ready to go.

Anything I missed?

Which way should we choose?




Attachment: bad.patch
Description: bad.patch

reply via email to

[Prev in Thread] Current Thread [Next in Thread]