[Ecls-list] Megapatch ahead

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Thu Sep 24 07:07:02 UTC 2009


Configuration flags?

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
>



-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com




More information about the ecl-devel mailing list