On Sat 07 May 2011 20:27, l...@gnu.org (Ludovic Courtès) writes:
>> * libguile/vm-engine.c (vm_engine): Cache the scm_i_thread* instead of
>> the dynstate, so we can use the thread for ticks.
>
> What effect does it have on performance? Registers are scarce on x86...
I did this because
* libguile/_scm.h (scm_set_fd_cloexec): New convenience macro for
setting the FD_CLOEXEC flah on platforms that support it; on other
platforms it's a no-op.
* libguile/objcodes.c (scm_load_objcode): Mark the objectcode's FD as
close-on-exec.
* libguile/scmsigs.c (start_signal_delivery_thread
This is supposed to prevent Guile to leak internal file descriptors
across an exec* system call. The Guile user has still to take care of
setting the CLOEXEC flag on all ports (e.g., using `port-for-each').
Linux's LVM tools are a nice test case for this, as they emit a warning
line for each leak
Hello!
l...@gnu.org (Ludovic Courtès) writes:
> Hello,
>
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Here’s an updated patch that strictly checks for ill-formed UTF-8
>> sequences, as Mark pointed out. It passes all the tests I recently
>> added to ports.test.
>
> I committed it, though Mark r
Hi Mark,
Mark H Weaver writes:
> In particular: `system*', `execl', `execlp', `execle', `environ', and
> `dynamic-args-call' use scm_i_allocate_string_pointers to convert a list
> of SCM strings into an argv-style array of C strings. That function
> does a simple memcpy for narrow strings, and
Hello!
"Andy Wingo" writes:
> commit a2a6c0e319b5c146c484cb1fe8ffc9b14b9a9876
> Author: Andy Wingo
> Date: Fri May 6 00:17:35 2011 +0200
>
> avoid tls gets when handling interrupts in the vm
>
> * libguile/__scm.h (SCM_ASYNC_TICK_WITH_CODE): Redefine to take a
> scm_i_threa
Recent changes to stable-2.0 seem to cause a deadlock in scwm. Here is the
last 10 frames of a backtrace.
-Dale
(gdb) bt
#0 0xb77fa424 in __kernel_vsyscall ()
#1 0xb734cf02 in __lll_lock_wait ()
at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:142
#2 0xb734839b in _L_l
