My two cents:
If chicken wants to be a practical Scheme system, as it claims on the
website, it should be possible to throw existing Scheme code on it and
have it run. If the code is broken: garbage in, garbage out; stay bug
compatible. If it can deal with the risks it takes: all is well.
On 2008-Aug-7, at 19:53, John Cowan wrote:
1) Run it in a separate process, which you can kill without damaging
yourself.
2) Use a modified version of eval to execute it that counts ticks.
3) Use a modified version of eval that polls for a thread termination
request.
I'd actually go
On Thu, Aug 7, 2008 at 6:03 PM, John Cowan [EMAIL PROTECTED] wrote:
Vincent Manis scripsit:
I'd prefer to have the manual document that to the best of our knowledge
thread-terminate works `correctly', but that its use is fraught with
design and testing problems, and therefore it should be
On Fri, Aug 8, 2008 at 9:12 AM, Vincent Manis [EMAIL PROTECTED] wrote:
On 2008-Aug-7, at 19:53, John Cowan wrote:
1) Run it in a separate process, which you can kill without damaging
yourself.
2) Use a modified version of eval to execute it that counts ticks.
3) Use a modified version of
On Sat, Aug 9, 2008 at 12:26 AM, John Cowan [EMAIL PROTECTED] wrote:
felix winkelmann scripsit:
4) Make the worker thread check a global (or thread-local, but
accessible from outside)
status and let it terminate itself.
The trouble is that it's running untrusted code.
One shouldn't do
On Sat, 9 Aug 2008, felix winkelmann wrote:
4) Make the worker thread check a global (or thread-local, but
accessible from outside)
status and let it terminate itself.
this is the way suggested in the srfi-18 docs, iirc, using the slot.
-elf
On Mon, Aug 4, 2008 at 9:28 PM, Jörg F. Wittenberger
[EMAIL PROTECTED] wrote:
Hi all,
Please find attached a self contained program, which is supposed to run
a useless thread for 3 seconds, kill it (logging a notice about an
exception being caught), create some garbage (logging a notice
On 2008-Aug-7, at 06:04, felix winkelmann wrote:
It must be added that `thread-terminate!' is a problematic
function: terminating a thread forcefully destroy an execution
context that doesn't necessarily expect to be terminated and
may leave any kind of system in an inconsistent state.
In fact,
Vincent Manis scripsit:
I'd prefer to have the manual document that to the best of our knowledge
thread-terminate works `correctly', but that its use is fraught with
design and testing problems, and therefore it should be avoided.
I'd go even further: KILL THE BEAST.
We've removed stuff a
Am Donnerstag, den 07.08.2008, 12:03 -0400 schrieb John Cowan:
Vincent Manis scripsit:
I'd prefer to have the manual document that to the best of our knowledge
thread-terminate works `correctly', but that its use is fraught with
design and testing problems, and therefore it should be
Jörg F. Wittenberger scripsit:
Nevertheless, I would not remove thread-terminate! Maybe repeat in the
manual those warnings from SRFI-18 that this is not exactly a nice call
to make. But why support half a srfi?
Because the SRFI turns out (based on experience with multi-threaded
though
Hi all,
(this is actually Joerg using Peter's machine).
Am Montag, den 04.08.2008, 21:20 -0500 schrieb Jim Ursetto:
Ran okay here. Do you have more stats about your environment, chicken
version, a less complicated program that can reproduce the problem,
etc.?
The environment, where the
Hi all,
Please find attached a self contained program, which is supposed to run
a useless thread for 3 seconds, kill it (logging a notice about an
exception being caught), create some garbage (logging a notice before
and afterwards) and exit properly.
To compile:
$ csc -o ttm ttm.scm
Here's the
On Mon, Aug 4, 2008 at 2:28 PM, Jörg F. Wittenberger
[EMAIL PROTECTED] wrote:
Please find attached a self contained program, which is supposed to run
a useless thread for 3 seconds, kill it (logging a notice about an
exception being caught), create some garbage (logging a notice before
and
I second Jim's call for more information and if possible a simpler
program. The program also ran fine on my system (Linux, Chicken
3.3.4), but when I compiled with csc -O2 I get this:
$ ./ttm
test
Load error in (define aa (with-timeout 3 (lambda () (do () (#f)
#t:(timeout) in (define aa
In fact, I discovered that even when ttm is compiled without
optimization options, it causes segmentation faults when run in a
continuous loop:
while (true); do ./ttm; done
(1st run okay...)
(2nd run -- out of memory)
(3rd run -- segmentation fault)
Predictably, the use of threads
On Mon, Aug 4, 2008 at 9:30 PM, Ivan Raikov [EMAIL PROTECTED] wrote:
The program also ran fine on my system (Linux, Chicken
3.3.4), but when I compiled with csc -O2 I get this [crash]
As an additional data point, compiling -O2 on my system does NOT
crash. System again:
$ csc -V
Version
Ok, I canalso confirm that the program does not crash with Chicken
3.3.4 on Mac OS X.
Jim Ursetto [EMAIL PROTECTED] writes:
As an additional data point, compiling -O2 on my system does NOT
crash. System again:
___
Chicken-users mailing list
18 matches
Mail list logo
