Stas Boukarev <stass...@gmail.com> writes:
> The first problem I encounter when building the latest ECL is a stray
> reference to ecl_query_all_processes_status. That's easily fixable, and
> the attached patch does that.
>
> diff --git a/src/c/unixsys.d b/src/c/unixsys.d
> index ea46754..667de72 100755
> --- a/src/c/unixsys.d
> +++ b/src/c/unixsys.d
> @@ -294,7 +294,7 @@ ecl_waitpid(cl_object pid, cl_object wait)
> if (Null(flag)) {
> /* We come from the parallel thread, must lock */
> ECL_WITH_LOCK_BEGIN(env, cl_core.external_processes_lock) {
> - ecl_query_all_processes_status(0);
> + si_wait_for_all_processes(0);
> } ECL_WITH_LOCK_END(env, cl_core.external_processes_lock);
> return;
> }
>
>
> Next, I get:
> ;*** Lisp core booted ****
> ECL (Embeddable Common Lisp)
>
> ;;;
> ;;; Welcome to bare.lsp. Let's bring this instance up!
> ;;;
> ;;;
> ;;; About to load lsp/load.lsp
> ;;;
> ;;; Loading src:lsp;export.lsp
> ;;; Unhandled lisp initialization error
> ;;; Message:
> STACK-OVERFLOW
> ;;; Arguments:
>
> Internal or unrecoverable error in:
>
> Lisp initialization error.
Ok, I didn't notice that ecl_query_all_processes_status was inside
si_wait_for_all_processes definition, that's what causes
the stack-overflow.
--
With best regards, Stas.
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
