Strange behaviour of release-foreground with optional parameter 'next'

Bug #1682867 reported by Syll on 2017-04-14
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Low
Unassigned

Bug Description

In toplevel REPL, run this code :

  (let ((thread2 (sb-thread:make-thread (lambda () (print "2")) :name "Thread 2")))
    (sb-thread:release-foreground thread2)
    (print (sb-thread::session-interactive-threads sb-thread::*session*))
    (finish-output))

=>

"2"
(#<SB-THREAD:THREAD "Thread 2" FINISHED values: "2" {1001FC20D3}>
 #<SB-THREAD:THREAD "main thread" RUNNING {1001F0E473}>)
NIL

Calling release-foreground places "Thread 2" in the interactive threads list but "main thread" remains in the list too. If there were several threads in the list, "main thread" would have been removed from the list.

So when giving foreground to another thread, current thread is removed from the list or not, depending of the state of the list, which is strange because there *is* another thread to place in the list. And keeping current thread in the list implies this thread will get foreground when 'next' thread looses it (ends / release foreground), so future behaviour depends on current state of the list.

In release-foreground, I think "(when next ...)" should be before "(when (rest ...))" : next interactive thread would be systemaically placed in the list and current thread would by systemaically removed from the list.

Maybe there is a special case if current thread is 'next' thread. Probably nothing should happen at all.

------------

$ sbcl --version
SBCL 1.3.15

$ uname -a
Linux yggdrasil 4.10.9-1-ARCH #1 SMP PREEMPT Sat Apr 8 12:39:59 CEST 2017 x86_64 GNU/Linux

* *features*
(:64-BIT :64-BIT-REGISTERS :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS
 :C-STACK-IS-CONTROL-STACK :COMMON-LISP :COMPACT-INSTANCE-HEADER
 :COMPARE-AND-SWAP-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF :FLOAT-EQL-VOPS
 :FP-AND-PC-STANDARD-SAVE :GENCGC :IEEE-FLOATING-POINT :IMMOBILE-CODE
 :IMMOBILE-SPACE :INLINE-CONSTANTS :INTEGER-EQL-VOP :LARGEFILE :LINKAGE-TABLE
 :LINUX :LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS
 :OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN
 :OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-POLL :OS-PROVIDES-PUTWC
 :OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES :PRECISE-ARG-COUNT-ERROR
 :RAW-INSTANCE-INIT-VOPS :RAW-SIGNED-WORD :SB-CORE-COMPRESSION :SB-DOC :SB-EVAL
 :SB-FUTEX :SB-LDB :SB-PACKAGE-LOCKS :SB-SIMD-PACK :SB-SOURCE-LOCATIONS
 :SB-THREAD :SB-UNICODE :SBCL :STACK-ALLOCATABLE-CLOSURES
 :STACK-ALLOCATABLE-FIXED-OBJECTS :STACK-ALLOCATABLE-LISTS
 :STACK-ALLOCATABLE-VECTORS :STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS
 :UNBIND-N-VOP :UNDEFINED-FUN-RESTARTS :UNIX :UNWIND-TO-FRAME-AND-CALL-VOP
 :X86-64)

Jan Moringen (scymtym) on 2017-04-15
Changed in sbcl:
status: New → In Progress
importance: Undecided → Low
assignee: nobody → Jan Moringen (scymtym)
Jan Moringen (scymtym) on 2017-05-22
Changed in sbcl:
status: In Progress → Fix Committed
assignee: Jan Moringen (scymtym) → nobody
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers