[Ecls-list] Megapatch ahead

[Kamil Shakirov]

Hi Juan,

I get the same result on Linux (ubuntu 9.04 x86).

On Thu, 2009-09-24 at 09:07 +0200, Juan Jose Garcia-Ripoll wrote:
> Configuration flags?

./configure --prefix=/usr/local --enable-boehm=included
--without-system-gmp --enable-threads --enable-unicode

> 
> On Thu, Sep 24, 2009 at 12:43 AM, Tobias C. Rittweiler <tcr at freebits.de> wrote:
> > Juan Jose Garcia-Ripoll writes:
> >
> >> Hi, a warning for everybody: stay with your current sources if you do
> >> not want to play with new features or help me with the changes I will
> >> be listing below.
> >>
> >> I am now uploading my latest developments in the field of signals,
> >> interrupts, exceptions, threads and the like. It is a mess of things
> >> that are fixed by these changes but basically it consists on the
> >> following.
> >>
> >> - ECL now implements a more clear model of handling unexpected events,
> >> which includes
> >>     + Hardware and software generated errors (floating point
> >> exceptions, page faults...)
> >>     + Externally generated interrupts and events
> >>     + Interrupts sent from one thread to another.
> >> - For events generated in the thread itself, the dispatch is normally
> >> local and it amounts to the thread being interrupted and signalling an
> >> error. When this happens may be controlled with the macros
> >> ext:without-interrupts, ext:with-interrupts, etc.
> >> - For events generated from the "outside", the detection and
> >> processing of such events _may_ happen in a separate thread. This is
> >> both safer and unavoidable in most operating systems. For instance,
> >> Windows executes the handler for Ctrl-C in a separate thread.
> >>
> >> I have tried to minimize the impact of these changes, but there will
> >> be unavoidable changes in the interface. For instance, when going
> >> multithreaded and pressing Ctrl-C in ECL, the environment will try to
> >> suspend all threads and launch a debugger session in a SEPARATE
> >> thread. This debugger will be able to interrupt other threads or
> >> continue execution as usual. It is unavoidable to query INTERACTIVELY
> >> the user which process should be interrupted or how.
> >
> > Trying to build from git, ecl_min gets stuck at
> >
> >  ;;;
> >  ;;; Welcome to bare.lsp. Let's bring this instance up!
> >  ;;;
> >  ;;;
> >  ;;; About to load lsp/load.lsp
> >  ;;;
> >  ;;; Loading src:lsp;export.lsp
> >  ;;; Loading src:lsp;defmacro.lsp
> >  ;;; Loading src:lsp;helpfile.lsp
> >  ;;; Loading src:lsp;evalmacros.lsp
> >  ;;; Loading src:lsp;cmuutil.lsp
> >  ;;; Loading src:lsp;autoload.lsp
> >  ;;; Loading src:lsp;setf.lsp
> >  ;;; Loading src:lsp;predlib.lsp
> >
> > Attaching strace on the process yields
> >
> >  futex(0x81483e4, 0x80 /* FUTEX_??? */, 0
> >
> > Even C-c'ing is blocked. This is Linux-x86-32.
> >
> > I'm on commit
> >
> >  commit bdf8d9d037cdd566b1305789e263be27b2977f2e
> >  Author: Juan Jose Garcia Ripoll <jjgarcia at jjgr-2.local>
> >  Date:   Wed Sep 23 23:52:47 2009 +0200
> >
> >  -T.
> >
> >
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry® Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9-12, 2009. Register now!
> > http://p.sf.net/sfu/devconf
> > _______________________________________________
> > Ecls-list mailing list
> > Ecls-list at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/ecls-list
> >
> 
> 
> 
-- 
--wbr.