October 2015 - ecl-devel - mailman3.common-lisp.net

Re: [Ecls-list] threading failures
by Daniel Kochmański 22 Jan '16

22 Jan '16

Hello, that's probably my fault, sorry. I've migrated bugs manually and probably missed this one (I remember this bug! but can't find anywhere). I'm adding it to regression tests in repository, thanks! Yes, old reports are unfortunately lost. As a sienote, please use ecl-devel(a)common-lisp.net mailing list – I'm closing the old one today. You can subscribe here https://mailman.common-lisp.net/listinfo/ecl-devel . All archives before 2015-08-10 are imported to the new one and gmane stream is redirected (if you use it). Regards, Daniel James M. Lawrence writes: > Hello, the threading bugs I reported a while ago appear to have not > survived the migration from sourceforge, and the old pages are now > 404'd. There were a number of test cases, including > > (defun test (message-count worker-count) > (let ((to-workers (mp:make-semaphore)) > (from-workers (mp:make-semaphore))) > (loop repeat worker-count > do (mp:process-run-function > "test" > (lambda () > (loop > (mp:wait-on-semaphore to-workers) > (mp:signal-semaphore from-workers))))) > (loop > (loop repeat message-count > do (mp:signal-semaphore to-workers)) > (loop repeat message-count > do (mp:wait-on-semaphore from-workers)) > (assert (zerop (mp:semaphore-count to-workers))) > (assert (zerop (mp:semaphore-count from-workers))) > (format t ".") > (finish-output)))) > > (defun run () > (test 10000 64)) > > RUN will eventually hang on all versions of ECL I've tried, including > the latest. Another test case was a variant of the above using a > homemade semaphore. I can rewrite that and other test cases, but > before doing so I'd like to know whether the old reports are really > lost or have survived in some form. > > Best, > lmj > > ------------------------------------------------------------------------------ > _______________________________________________ > Ecls-list mailing list > Ecls-list(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ecls-list -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi

3 11

GC and Threading
by Bix 06 Nov '15

06 Nov '15

Hi, just two quick question: 1. Is it possible to disable the threading model and have multiple thread to eval the code or have one ECL per thread? 2. Can the garbage collector be disabled at all and have the memory managed in a reference counting fashion? I like to embed the ECL in my multithread application but I've got very restrictive constrain about thread and memory: * I can not spawn new thread but I've got concurrent thread to execute ecl call. * A component that bring GC would probably not be accepted and I'm wondering if there is an alternative to that in ECL, or at least have more control how/when GC will be run. Can you point me out where to look in the source code to understand those aspect of ECL? Thanks in advance. f.

5 7

ASDF 3.1.6 is released
by Robert Goldman 17 Oct '15

17 Oct '15

We would like to announce the release of ASDF 3.1.6, the latest bug fix release for ASDF. As usual many thanks are due to Faré for many bug fixes, clean ups, explanations, etc. Thanks are also owed to Dave Cooper, for testing on the Windows platform, enabling the maintainers to test on Windows, and identifying uncaught bugs. Thanks to Anton Vodonosov for testing the release candidate against Quicklisp on cl-test-grid. Finally, thanks to all who found bugs, provided patches, and used prerelease candidates. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.1.6. 3.1.6 does not introduce any API incompatibilities that we know of, and contains significant bug fixes on multiple platforms and implementations. See the Changelog (below) for a list of the major bug fixes. Details on minor bugfixes can be found at launchpad.net/asdf We had hoped that 3.1.5 would be the last 3.1.x bug fix release, paving the way for us to move to developing ASDF 3.2, which we expect will add new features. Maybe this time! Here is the changelog entry for 3.1.6: Bug fix and portability release: * Fix backtrace on SBCL. * Fix RUN-PROGRAM of string (shell command) on Windows SBCL (ticket #1501373). * Fix a number of issues with bundle operations (especially on non-C-compiler-based implementations). * Fix component-finding in package-inferred-system. * Fix race condition between multiple concurrent lisp processes doing ASDF builds (ticket #1483948). * Fix misplaced fasl cache on Windows. * Miscellaneous bug fixes. * Documentation improvements. -- Robert P. Goldman <rpgoldman(a)sift.net> Sat, 17 Oct 2015 15:01:34 -0500

1 0

Fwd: Re: [monolith builds]
by Daniel Kochmański 04 Oct '15

04 Oct '15

Current ML is ecl-devel(a)common-lisp.net, I'm forwarding this mail there. Daniel Kochmański writes: > Faré writes: > >> [Adding ECL-list to this conversation, that I believe should be >> publicly archived] > > Good idea. >> >> On Fri, Oct 2, 2015 at 7:24 AM, Daniel Kochmański <daniel(a)turtleware.eu> wrote: >>> Hey, >>> >>> when fixing problem with randomized names etc I have taken a closer look >>> at the build process. You asked earlier how ECL manages to do monolithic >>> builds. >>> >>> Each module is initialized with a special function which registers the >>> whole module and creates lisp objects. Before calling this function ECL >>> isn't aware of the existance of it neither it has environment. >>> >>> Module may be composed on other modules. Builder, when constructing >>> initialization function for "top module" gathers all submodules (object >>> files or libraries) and parses the binary file to find special tag which >>> contains name of functions which initialize submodules. Top module in >>> it's initialization functions calls (beside the other things) all >>> submodule initialization functions. Then it concatanates all of them in >>> .a, .fasl, .so, ... files >>> >>> Top-module >>> Sub-module-1 >>> Sub-module-2 >>> … >>> >>> So it is guaranteed, that if this top-module will be embedded in the >>> other one it's special tag will be found first and the correct >>> initialization function will be called (which will initialize the futher >>> submodules). >>> >>> This description might be not 100% accurate but I believe it is how >>> things work there. Reverse engineering might be misleading :-) >>> >>> I've fixed bundles once again and ASDF passes tests. It's your call if >>> you want to enable it by default. >>> >>> Best regards, >>> Daniel >>> >>> -- >>> Daniel Kochmański | Poznań, Poland >>> ;; aka jackdaniel >>> >>> "Be the change that you wish to see in the world." - Mahatma Gandhi >> >> Thanks for these explanations. >> >> Questions: >> >> 1- what is a "tag" in this context? > > Tag is a string embedded in the C code with deterministic prefix > followed by a name of the object function. For instance assuming > initialization function has name lib_init_xyz, then it will look > something like: > > void lib_init_xyz (cl_object block) { > ... > Cblock->cblock.data_text = (const cl_object *)"@EcLtAg_lib:lib_init_xyz@"; > ... > } > > When emiting code for top module we scan the binary object files for > appropriate tag (in this example @EcLAg_lib) to find the inititalization > function name which we embed in a source code as a normall call: > > void lib_init_top_module (cl_object block) { > ... > Cblock->cblock.data_text = (const cl_object *)"@EcLtAg_lib:lib_init_top_module@"; > ... > lib_init_xyz(block); > ... > } > > Note that now function names are randomized and this is mere a > psudocode. For further details consult src/cmp/cmpmain.lsp. > >> >> 2- once again, why not use the linker support for initialization? >> If behavior has to depend on whether ECL was initialized yet, >> the initialization could consider in calling ecl_register_init_function, >> which depending on whether ECL was booted, would either call the function >> and/or add it to a hook. >> See once again attached files on how to use linker support for >> initialization. > > Fact that we might bundle many objects in one archive doesn't mean that > they don't have dependencies on one another. *I think* that we have to > strictly control initialization order. It's possible that I'm wrong here > though. > > Also do we want to *always* initialize *everything* what is linked? We > may have compiled-in support for number of lisp libraries in one module > just for conveniance and require them on demand depending on the > application using our code. > > I'm guessing here since it's a design decision made by someone > else. Your proposition is surely worth investigating - it is like it is > because it was that way when I approached the codebase. >> >> 3- How does MKCL do it? > > MKCL creates these initialization functions but when it loads files it > "slurps" some vector with objects - it doesn't call initialization > functions. Don't know if function creation is > rendundant/obsolete/inconsistent/correct - you have to ask MKCL > maintainer for details. It looks to me that it works for files built > with MKCL but breaks linking from the outer code with the libraries > created by it (and by breakage I mean that compilation goes fine but > such modules doesn't work). Once again I'm not 100% about that. MKCL > code diverged a lot with this regards. > > Regards, > Daniel > >> >> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org >> Suppose 2/3 Congress were incinerated, what would we lose to offset our gain >> of their salaries and the salaries of their parasites? — H. L. Mencken -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi

2 3