When running a short-lived program with run-program, it takes a second for run-program to return.

CL-USER> (time (sb-ext:run-program "/usr/bin/true" '()))
Evaluation took:
  1.004 seconds of real time
  0.006292 seconds of total run time (0.001380 user, 0.004912 system)
  0.60% CPU
  1,705,702,705 processor cycles
  0 bytes consed
  
#<SB-IMPL::PROCESS :EXITED 0>

I can only reproduce this when there are multiple threads (e.g. when slime is running). When running from the command line (in a single thread), it returns in 0.004s.

I had a look at the source code, and it seems that process-wait calls serve-all-events with a timeout of 1 second. Could it be that the SIGCHLD is delivered to a different thread and the select(2) is not interrupted? I tried TRACEing the sigchld-handler, but that didn't work. When I trace get-processes-status-changes (called from sigchld-handler), I get the following output:

CL-USER> (trace sb-impl::get-processes-status-changes)
(SB-IMPL::GET-PROCESSES-STATUS-CHANGES)

CL-USER> (time (sb-ext:run-program "/usr/bin/true" '()))
  0: (SB-IMPL::GET-PROCESSES-STATUS-CHANGES)
  0: SB-IMPL::GET-PROCESSES-STATUS-CHANGES returned NIL
  0: (SB-IMPL::GET-PROCESSES-STATUS-CHANGES)
  0: SB-IMPL::GET-PROCESSES-STATUS-CHANGES returned NIL
***Here there is a pause***
  0: (SB-IMPL::GET-PROCESSES-STATUS-CHANGES)
  0: SB-IMPL::GET-PROCESSES-STATUS-CHANGES returned NIL
Evaluation took:
  1.003 seconds of real time
  0.007999 seconds of total run time (0.002631 user, 0.005368 system)
  0.80% CPU
  4 forms interpreted
  1,706,189,664 processor cycles
  65,536 bytes consed
  
  0: (SB-IMPL::GET-PROCESSES-STATUS-CHANGES)
  0: SB-IMPL::GET-PROCESSES-STATUS-CHANGES returned NIL
#<SB-IMPL::PROCESS :EXITED 0>


The first two calls are almost immediate, followed after a pause by the third one and time output. The second call could be the one called from sigchld-handler.
Manually sending 'kill -CHLD <pid>' from a terminal triggers a call to get-processes-status-changes.

I'm running SBCL 1.1.14 (compiled from source --with-sb-thread), on Mac OS X 10.9.1.

CL-USER> (lisp-implementation-version)
"1.1.14"
CL-USER> *features*
(CFFI-FEATURES:FLAT-NAMESPACE CFFI-FEATURES:X86-64 CFFI-FEATURES:UNIX
 CFFI-FEATURES:DARWIN :CFFI CFFI-SYS::FLAT-NAMESPACE :SWANK :QUICKLISP :ASDF3
 :ASDF2 :ASDF :OS-UNIX :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :ALIEN-CALLBACKS
 :ANSI-CL :ASH-RIGHT-VOPS :BSD :C-STACK-IS-CONTROL-STACK :COMMON-LISP
 :COMPARE-AND-SWAP-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :DARWIN
 :DARWIN9-OR-BETTER :FLOAT-EQL-VOPS :GENCGC :IEEE-FLOATING-POINT
 :INLINE-CONSTANTS :INODE64 :LINKAGE-TABLE :LITTLE-ENDIAN
 :MACH-EXCEPTION-HANDLER :MACH-O :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS
 :OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN
 :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES
 :RAW-INSTANCE-INIT-VOPS :SB-DOC :SB-EVAL :SB-LDB :SB-PACKAGE-LOCKS
 :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-TEST :SB-THREAD :SB-UNICODE :SBCL
 :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS
 :STACK-GROWS-DOWNWARD-NOT-UPWARD :UD2-BREAKPOINTS :UNIX
 :UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)

Anybody any ideas?

Regards,
Peter