headers
Raymond Toy | 1 Feb 04:27
Picon

Re: gc & blocked signals

On 1/31/12 2:03 PM, Helmut Eller wrote:
> I think there is a problem related to blocked signals and garbage
> collection:
>
> 1. Start cmucl -noinit -eval '(loop (ext:gc :full t))' 
>    in a terminal and let it run.
>
> 2. Under Linux,  cat /proc/≤pid>/status  shows that SigBlk is 0 i.e. 
>    no signals are blocked.
>
> 3. Interrupt the loop with C-c (SIGINT) and wait for the debugger.
>
> 4. SigBlk is still 0.
>
> 5. Type c to continue the loop.
>
> 6. SigBlk is now 000000001fc90000
>
> That's a bug, right?  It should again be zero.
Yeah, that looks like a bug.  I think the problem is not with gc, but
with the signal handler(s).  I was planning on doing some work on the
signal handlers to make them simpler, based on what Carl did for
Windows.  This should make them simpler and safer.  Don't know if it
will take care of this problem or not.

>  29 SIGIO
>
> SLIME uses SIGIO on a socket and if that stays blocked then SLIME can't
> interrupt the Lisp process.  Also note that C-z in the terminal doesn't
(Continue reading)

Permalink | Reply | 4 comments |
headers
Helmut Eller | 1 Feb 09:32

Re: gc & blocked signals

* Raymond Toy [2012-02-01 03:27] writes:

> Yeah, that looks like a bug.  I think the problem is not with gc, but
> with the signal handler(s).  I was planning on doing some work on the
> signal handlers to make them simpler, based on what Carl did for
> Windows.  This should make them simpler and safer.  Don't know if it
> will take care of this problem or not.

The problem doesn't occur with an empty loop.  Therefore I think it has
something to do with GC.

>
>>  29 SIGIO
>>
>> SLIME uses SIGIO on a socket and if that stays blocked then SLIME can't
>> interrupt the Lisp process.  Also note that C-z in the terminal doesn't
>
> Does SIGIO actually work for you?  I stopped using it long ago because
> it caused strange errors to occur (on darwin).  I think it's because
> SIGIO causes interrupts at bad places because cmucl isn't really
> interrupt-safe.

Works good enough for me (on Linux).  The GC should of course be
interrupt-safe.  The stream code is not reentrant so it is problematic
to use streams in signal handlers.  SLIME tries to be careful when
reading/writing to it's own stream and tries to delay interrupts to
safe-points.  SLIME can't fix other streams or non-reentrant code, but
the situation there is IMO the same as if the debugger is invoked with
SIGINT.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Marco Antoniotti | 1 Feb 14:11
Picon

ELS 2012, Zadar, Croatia

Apologies for the multiple postings. 

PAPER SUBMISSION DEADLINE EXTENDED 

European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012 

http://european-lisp-symposium.org 

The purpose of the European Lisp Symposium is to provide a forum for 
the discussion and dissemination of all aspects of design, 
implementation and application of any of the Lisp and Lisp-inspired 
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, 
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We 
encourage everyone interested in Lisp to participate. 

The main theme of the 2012 European Lisp Conference is 
"Interoperability: Systems, Libraries, Workflows".  Lisp based and 
functional-languages based systems have grown a variety of solutions 
to become more and more integrated with the wider world of Information 
and Communication Technologies in current use.  There are several 
dimensions to the scope of the solutions proposed, ranging from 
"embedding" of interpreters in C-based systems, to the development of 
abstractions levels that facilitate the expression of complex context 
dependent tasks, to the construction of exchange formats handling 
libraries, to the construction of theorem-provers for the "Semantic 
Web".  The European Lisp Symposium 2012 solicits the submission of 
papers with this specific theme in mind, alongside the more 
traditional tracks which have appeared in the past editions. 

We invite submissions in the following forms:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raymond Toy | 1 Feb 18:20
Picon

Re: gc & blocked signals

On Wed, Feb 1, 2012 at 12:32 AM, Helmut Eller <heller <at> common-lisp.net>wrote:

> * Raymond Toy [2012-02-01 03:27] writes:
>
> > Yeah, that looks like a bug.  I think the problem is not with gc, but
> > with the signal handler(s).  I was planning on doing some work on the
> > signal handlers to make them simpler, based on what Carl did for
> > Windows.  This should make them simpler and safer.  Don't know if it
> > will take care of this problem or not.
>
> The problem doesn't occur with an empty loop.  Therefore I think it has
> something to do with GC.
>

Ok. Can you write up a ticket for this?

>
> >
> >>  29 SIGIO
> >>
> >> SLIME uses SIGIO on a socket and if that stays blocked then SLIME can't
> >> interrupt the Lisp process.  Also note that C-z in the terminal doesn't
> >
> > Does SIGIO actually work for you?  I stopped using it long ago because
> > it caused strange errors to occur (on darwin).  I think it's because
> > SIGIO causes interrupts at bad places because cmucl isn't really
> > interrupt-safe.
>
> Works good enough for me (on Linux).  The GC should of course be
> interrupt-safe.  The stream code is not reentrant so it is problematic
(Continue reading)

Permalink | Reply | 2 comments |
headers
Helmut Eller | 1 Feb 19:26

Re: gc & blocked signals

* Raymond Toy [2012-02-01 17:20] writes:

> Ok. Can you write up a ticket for this?

Sure. See: http://trac.common-lisp.net/cmucl/ticket/55

Helmut

_______________________________________________
cmucl-imp mailing list
cmucl-imp <at> cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp
Permalink | Reply | 1 comment |
headers
Raymond Toy | 1 Feb 20:47
Picon

Re: gc & blocked signals

On Wed, Feb 1, 2012 at 10:26 AM, Helmut Eller <heller <at> common-lisp.net>wrote:

> * Raymond Toy [2012-02-01 17:20] writes:
>
> > Ok. Can you write up a ticket for this?
>
> Sure. See: http://trac.common-lisp.net/cmucl/ticket/55
>
>
Thanks!  Now I won't forget about it.

Ray
_______________________________________________
cmucl-imp mailing list
cmucl-imp <at> cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp
Permalink | Reply | 0 comments |
headers
Raymond Toy | 3 Feb 18:15
Picon

Re: gc & blocked signals

On Tue, Jan 31, 2012 at 2:03 PM, Helmut Eller <heller <at> common-lisp.net>wrote:

> I think there is a problem related to blocked signals and garbage
> collection:
>
> 1. Start cmucl -noinit -eval '(loop (ext:gc :full t))'
>   in a terminal and let it run.
>
> 2. Under Linux,  cat /proc/≤pid>/status  shows that SigBlk is 0 i.e.
>   no signals are blocked.
>
> 3. Interrupt the loop with C-c (SIGINT) and wait for the debugger.
>
> 4. SigBlk is still 0.
>
> 5. Type c to continue the loop.
>
> 6. SigBlk is now 000000001fc90000
>
> That's a bug, right?  It should again be zero.
>
>
For your example with just a simple loop, a C-c causes an interrupt to
happen right away, so things work.  But when GC is running, interrupts are
disabled, so the C-c is remembered and and deferred to a later time and
then handled with a pendingInterrupt trap.  This is the main difference
between the two cases.

I think the problem is in interrupt_handle_pending:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Carl Shapiro | 4 Feb 01:47
Picon

Re: gc & blocked signals

On Fri, Feb 3, 2012 at 9:15 AM, Raymond Toy <toy.raymond <at> gmail.com> wrote:
> NSIG = 65 and LONG_BIT = 32 on my machine, so memcpy only copies 2 bytes.
> I think we really want to copy at least 64 bits or 8 bytes.  If I modify
> this code to copy 8 bytes, SigBlk is now 0 after returning, and C-c
> continues to work.

This looks like my fault

http://common-lisp.net/gitweb?p=projects/cmucl/cmucl.git;a=commit;h=342beebbfed6718f0bbc4276f29a18d0f7356ec8

LONG_BIT should have been CHAR_BIT.

I am surprised that the C library NSIG is now 65.  When I made this
change, the C library on the machine I used defined NSIG as 1024 but
the kernel data structure knew it was 64.  For example, compare

http://lxr.linux.no/#linux+v3.2.4/arch/x86/include/asm/signal.h

with

http://fxr.watson.org/fxr/source/sysdeps/unix/sysv/linux/bits/signum.h?v=GLIBC27#L69

Using the wrong definition of NSIG may cause a corruption.
_______________________________________________
cmucl-imp mailing list
cmucl-imp <at> cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp
Permalink | Reply | 2 comments |
headers
Raymond Toy | 4 Feb 16:33
Picon

Re: gc & blocked signals

On 2/3/12 4:47 PM, Carl Shapiro wrote:
>
> I am surprised that the C library NSIG is now 65.  When I made this
> change, the C library on the machine I used defined NSIG as 1024 but
> the kernel data structure knew it was 64.  For example, compare
So previously, the code was copying 32 bytes?  That seems like too much too.

NSIG is 65 on an Ubuntu 10 system.  It's also 65 on my OpenSuSE 11.3
system that I normally use to build cmucl.

Ray

_______________________________________________
cmucl-imp mailing list
cmucl-imp <at> cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp
Permalink | Reply | 1 comment |
headers
Raymond Toy | 4 Feb 17:48
Picon

Feb snapshot tagged

The February snapshot has been tagged.  Binaries will be uploaded soon.

The changes for this snapshot are:

o utf-8 built into the core
o a bug in unicode-complete-name has been fixed
o Helmut's blocked signals issue

One other change is that the ppc port has been revived and is up-to-date
with the current sources.  However, only a unicode build is available. 
Many thanks to Robert Smith for making a ppc machine available for this.

Ray

_______________________________________________
cmucl-imp mailing list
cmucl-imp <at> cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp
Permalink | Reply | 0 comments |

Gmane