Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #32547 > unrolled thread
| Started by | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| First post | 2014-07-22 14:44 -0700 |
| Last post | 2014-07-30 22:55 -0700 |
| Articles | 20 on this page of 97 — 20 participants |
Back to article view | Back to comp.lang.forth
What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-22 14:44 -0700
Re: What for Break Key No Work? Roger Levy <roger.levy@gmail.com> - 2014-07-22 14:50 -0700
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-22 15:04 -0700
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-22 16:03 -0700
Re: What for Break Key No Work? BruceMcF <agila61@netscape.net> - 2014-07-22 18:34 -0700
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-22 19:32 -0700
Re: What for Break Key No Work? Spam@ControlQ.com - 2014-07-22 22:43 -0400
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-23 09:57 -0700
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-23 07:12 -1000
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-23 10:15 -0700
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-22 22:44 -0400
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-23 09:58 -0700
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-23 21:28 -1000
Re: What for Break Key No Work? BruceMcF <agila61@netscape.net> - 2014-07-23 13:12 -0700
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-23 14:52 -0700
Re: What for Break Key No Work? Mark Wills <markwills1970@gmail.com> - 2014-07-24 01:54 -0700
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-24 07:54 -0400
Re: What for Break Key No Work? Mark Wills <markwills1970@gmail.com> - 2014-07-24 06:49 -0700
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-24 10:39 -0400
Re: What for Break Key No Work? bruce.mcfarling@gmail.com - 2014-07-24 08:52 -0700
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-24 13:07 -0500
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-25 10:50 +0000
Re: What for Break Key No Work? Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-25 14:38 +0200
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-25 17:07 +0000
Re: What for Break Key No Work? Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-26 00:36 +0200
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-27 13:47 +0000
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-25 09:21 -0500
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-25 17:10 +0000
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-26 04:38 -0500
Re: What for Break Key No Work? Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-26 15:56 +0200
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-27 13:27 +0000
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-27 09:36 -0500
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-28 11:38 +0000
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-28 10:42 -0500
Re: What for Break Key No Work? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-25 16:56 -0400
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-26 09:33 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-24 19:40 -0400
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-25 00:00 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-24 22:17 -0400
Re: What for Break Key No Work? bruce.mcfarling@gmail.com - 2014-07-25 06:54 -0700
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-25 13:13 -0400
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-25 13:24 -0400
Re: What for Break Key No Work? bruce.mcfarling@gmail.com - 2014-07-25 14:37 -0700
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-25 19:01 -0400
Re: What for Break Key No Work? bruce.mcfarling@gmail.com - 2014-07-25 16:20 -0700
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-25 22:02 -0400
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-25 22:17 -0400
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-26 09:09 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-26 05:36 -0400
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-26 04:41 -0500
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-26 22:50 -0400
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-27 02:49 -0500
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-27 15:08 -0400
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-27 14:11 -0500
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-28 12:00 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-28 10:41 -0400
Re: What for Break Key No Work? Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-27 14:31 +0200
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-27 13:08 +0000
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-27 19:37 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-27 16:35 -0400
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-27 22:24 +0000
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-28 13:14 +0000
Re: What for Break Key No Work? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-28 03:41 -0500
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-28 12:09 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-28 10:48 -0400
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-28 15:29 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-28 14:30 -0400
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-29 08:12 +0000
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-28 13:10 +0000
Re: What for Break Key No Work? bruce.mcfarling@gmail.com - 2014-07-27 11:33 -0700
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-28 11:55 +0000
Re: What for Break Key No Work? "Alex McDonald" <blog@rivadpm.com> - 2014-07-28 14:03 +0100
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-27 13:02 +0000
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-26 08:57 +0000
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-26 05:05 -0400
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-26 09:20 +0000
Re: What for Break Key No Work? "Alex McDonald" <blog@rivadpm.com> - 2014-07-23 23:48 +0100
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-24 04:53 -0400
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-24 10:59 +0000
Re: What for Break Key No Work? mhx@iae.nl - 2014-07-24 04:23 -0700
Re: What for Break Key No Work? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-24 19:28 +0000
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-24 13:01 -1000
Re: What for Break Key No Work? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-07-25 10:13 +0200
Re: What for Break Key No Work? "Elizabeth D. Rather" <erather@forth.com> - 2014-07-22 17:11 -1000
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-23 09:59 -0700
Re: What for Break Key No Work? David Schultz <abuse@127.0.0.1> - 2014-07-22 17:47 -0500
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-22 19:12 -0400
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-22 16:21 -0700
Re: What for Break Key No Work? rickman <gnuarm@gmail.com> - 2014-07-22 22:51 -0400
Re: What for Break Key No Work? Matthias Trute <matthias.trute@gmail.com> - 2014-07-23 02:18 -0700
Re: What for Break Key No Work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-23 13:21 +0000
Re: What for Break Key No Work? Jason Damisch <jasondamisch@yahoo.com> - 2014-07-23 10:02 -0700
Re: What for Break Key No Work? Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-24 04:10 +0200
Re: What for Break Key No Work? mhx@iae.nl - 2014-07-23 13:45 -0700
Re: What for Break Key No Work? BruceMcF <agila61@netscape.net> - 2014-07-23 16:37 -0700
Re: What for Break Key No Work? "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2014-07-30 16:13 -0700
Re: What for Break Key No Work? francois.ganza@wanadoo.fr - 2014-07-30 22:55 -0700
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-24 13:07 -0500 |
| Message-ID | <ZYidnYKjk63R1kzOnZ2dnUVZ_jmdnZ2d@supernews.com> |
| In reply to | #32625 |
bruce.mcfarling@gmail.com wrote: > On Thursday, July 24, 2014 10:39:21 AM UTC-4, rickman wrote: >> You don't need to check at every semi do you? I think once around the >> loop is enough. The semi is used greatly and adding any code to that >> would slow down the process. Adding it to the looping words would not >> have as much impact. > > Checking it in BRANCH and ?BRANCH (or whatever the branching > operations that implement the loops are called in the implementation > at hand) might be more often than checking it at SEMI if there are > nothing but primitives in the loop ... but BRANCH and ?BRANCH would > be the place to check it if you wanted to go that route, as that is > precisely where you can get caught in an endless loop. > > Doing it with an interrupt seems a more natural approach, if > available. Indeed it is, but you have to guarantee that at every point it's possible to abort without breaking something. As I mentioned before, I reckon the Java approach is the best I've seen: have every backward branch (except perhaps DO..LOOPs, which are hopefully finite) and every return read (or write) a magic address. When you want to interrupt a running program, read- (or write-) protect that page. From the resulting trap, THROW an exception. That way you get all locks released etc. and a nice graceful return to the outer interpreter. It doesn't work if you're stuck in a loop that doesn't poll, such as calling a blocking system call. In that case, it really is necessary to force a return from the call. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-25 10:50 +0000 |
| Message-ID | <2014Jul25.125044@mips.complang.tuwien.ac.at> |
| In reply to | #32626 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Doing it with an interrupt seems a more natural approach, if
>> available.
>
>Indeed it is, but you have to guarantee that at every point it's
>possible to abort without breaking something.
>
>As I mentioned before, I reckon the Java approach is the best I've
>seen: have every backward branch (except perhaps DO..LOOPs, which are
>hopefully finite) and every return read (or write) a magic address.
>When you want to interrupt a running program, read- (or write-)
>protect that page. From the resulting trap, THROW an exception. That
>way you get all locks released etc. and a nice graceful return to the
>outer interpreter.
That's quite an effort. And quite contrary to Chuck Moore's approach
of establishing state when you start (Thinking Forth p. 212) instead
of restoring it when you finish that you advocated previously.
Gforth directly throws when it receives an asynchronous signal. My
experience is that, while there is no guarantee, nothing was broken
unexpectedly yet. We restore state when we finish in a number of
places, and that does prevent real problems (we experienced such
problems earlier).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-07-25 14:38 +0200 |
| Message-ID | <lqtj38$qoj$1@online.de> |
| In reply to | #32641 |
Anton Ertl wrote: > That's quite an effort. And quite contrary to Chuck Moore's approach > of establishing state when you start (Thinking Forth p. 212) instead > of restoring it when you finish that you advocated previously. > > Gforth directly throws when it receives an asynchronous signal. My > experience is that, while there is no guarantee, nothing was broken > unexpectedly yet. We restore state when we finish in a number of > places, and that does prevent real problems (we experienced such > problems earlier). The only problems I have is with the memory allocation exceptions on Linux. You can actually turn problems with the memory allocater into calling a function which then can throw an exception, but doing so breaks thread- savety of the entire memory allocater, because according to Ulrich Drepper, it is not possible to have that exception hook implemented in a thread-safe way m(. Hm, it's probably possible to open a bug report now that Ulrich Drepper isn't maintainer anymore. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-25 17:07 +0000 |
| Message-ID | <2014Jul25.190716@mips.complang.tuwien.ac.at> |
| In reply to | #32642 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Gforth directly throws when it receives an asynchronous signal. My
>> experience is that, while there is no guarantee, nothing was broken
>> unexpectedly yet. We restore state when we finish in a number of
>> places, and that does prevent real problems (we experienced such
>> problems earlier).
>
>The only problems I have is with the memory allocation exceptions on Linux.
>You can actually turn problems with the memory allocater into calling a
>function which then can throw an exception, but doing so breaks thread-
>savety of the entire memory allocater, because according to Ulrich Drepper,
>it is not possible to have that exception hook implemented in a thread-safe
>way m(. Hm, it's probably possible to open a bug report now that Ulrich
>Drepper isn't maintainer anymore.
You lost me here. What exceptions do you mean?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-07-26 00:36 +0200 |
| Message-ID | <lqum4t$edo$1@online.de> |
| In reply to | #32651 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>Anton Ertl wrote: >>> Gforth directly throws when it receives an asynchronous signal. My >>> experience is that, while there is no guarantee, nothing was broken >>> unexpectedly yet. We restore state when we finish in a number of >>> places, and that does prevent real problems (we experienced such >>> problems earlier). >> >>The only problems I have is with the memory allocation exceptions on >>Linux. You can actually turn problems with the memory allocater into >>calling a function which then can throw an exception, but doing so breaks >>thread- savety of the entire memory allocater, because according to Ulrich >>Drepper, it is not possible to have that exception hook implemented in a >>thread-safe >>way m(. Hm, it's probably possible to open a bug report now that Ulrich >>Drepper isn't maintainer anymore. > > You lost me here. What exceptions do you mean? Just try this: 10 allocate throw dup 20 - 50 erase free throw It will print diagnostic informations from free() and malloc() about the corrupted memory - and that freezes Gforth, making any further diagnostics impossible (e.g. printing a backtrace). There is a debugging call, mcheck(), which allows to hook in your own memory exception handling. But using that makes the entire malloc() and free() thread-unsafe, so it is not an option. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-27 13:47 +0000 |
| Message-ID | <2014Jul27.154750@mips.complang.tuwien.ac.at> |
| In reply to | #32662 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Anton Ertl wrote:
>>>> Gforth directly throws when it receives an asynchronous signal. My
>>>> experience is that, while there is no guarantee, nothing was broken
>>>> unexpectedly yet. We restore state when we finish in a number of
>>>> places, and that does prevent real problems (we experienced such
>>>> problems earlier).
>>>
>>>The only problems I have is with the memory allocation exceptions on
>>>Linux. You can actually turn problems with the memory allocater into
>>>calling a function which then can throw an exception, but doing so breaks
>>>thread- savety of the entire memory allocater, because according to Ulrich
>>>Drepper, it is not possible to have that exception hook implemented in a
>>>thread-safe
>>>way m(. Hm, it's probably possible to open a bug report now that Ulrich
>>>Drepper isn't maintainer anymore.
>>
>> You lost me here. What exceptions do you mean?
>
>Just try this:
>
>10 allocate throw
>dup 20 - 50 erase
>free throw
>
>It will print diagnostic informations from free() and malloc() about the
>corrupted memory - and that freezes Gforth, making any further diagnostics
>impossible (e.g. printing a backtrace). There is a debugging call,
>mcheck(), which allows to hook in your own memory exception handling. But
>using that makes the entire malloc() and free() thread-unsafe, so it is not
>an option.
Ok, that's a synchronous event, not an asynchronous one, so it's
somewhat besides the Ctrl-C discussion.
Anyway, I guess if we really want that, the way to go is to have our
own malloc() and free() implementation. E.g., my garbage collector
has one that uses only out-of-band information for managing its
memory, and therefore might be less vulnerable to such attacks. It
was not intended to be thread-safe, though, so I don't know how much
it would take to make it thread-safe.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-25 09:21 -0500 |
| Message-ID | <5JCdndHx1dFQ-k_OnZ2dnUVZ8jmdnZ2d@supernews.com> |
| In reply to | #32641 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> Doing it with an interrupt seems a more natural approach, if >>> available. >> >>Indeed it is, but you have to guarantee that at every point it's >>possible to abort without breaking something. >> >>As I mentioned before, I reckon the Java approach is the best I've >>seen: have every backward branch (except perhaps DO..LOOPs, which are >>hopefully finite) and every return read (or write) a magic address. >>When you want to interrupt a running program, read- (or write-) >>protect that page. From the resulting trap, THROW an exception. That >>way you get all locks released etc. and a nice graceful return to the >>outer interpreter. > > That's quite an effort. It is the simplest correct solution of which I know, which is why I mention it here. In general, asynchronous exceptions are a hard problem. > And quite contrary to Chuck Moore's approach of establishing state > when you start (Thinking Forth p. 212) instead of restoring it when > you finish that you advocated previously. Hmm. The connection with Chuck's remarks on page 212 is at most tenuous. > Gforth directly throws when it receives an asynchronous signal. My > experience is that, while there is no guarantee, nothing was broken > unexpectedly yet. I suppose it depends on whether you consider a break to be a programmer-only best-effort facility or something that can be used to shut down an application gracefully. Even as a programmer-only facility, if you're holding any locks at all you must release them when a thread terminates, otherwise next time you try to run your application it might not even start. (And you may be halfway through modifying e.g. a doubly-linked list, perhaps during an ALLOCATE or a FREE, in which case your heap is now corrupt, etc., etc.) So, simply returning to QUIT doesn't do it. Programs acquiring locks to make sure that they do so with a CATCH block to release them. That's good practice anyway, of course, and it's no harder than disk GET ['] foo CATCH disk RELEASE throw > We restore state when we finish in a number of places, and that does > prevent real problems (we experienced such problems earlier). Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-25 17:10 +0000 |
| Message-ID | <2014Jul25.191024@mips.complang.tuwien.ac.at> |
| In reply to | #32646 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>> Doing it with an interrupt seems a more natural approach, if
>>>> available.
>>>
>>>Indeed it is, but you have to guarantee that at every point it's
>>>possible to abort without breaking something.
>>>
>>>As I mentioned before, I reckon the Java approach is the best I've
>>>seen: have every backward branch (except perhaps DO..LOOPs, which are
>>>hopefully finite) and every return read (or write) a magic address.
>>>When you want to interrupt a running program, read- (or write-)
>>>protect that page. From the resulting trap, THROW an exception. That
>>>way you get all locks released etc. and a nice graceful return to the
>>>outer interpreter.
>>
>> That's quite an effort.
>
>It is the simplest correct solution of which I know, which is why I
>mention it here.
Probably. Hardening all the library calls against being interrupted
at any time is probably harder (depending on the amount of library
stuff). And then you have to take similar care for the Forth code you
write; that gets a little simpler with your approach, because the
interruption can only happen on backwards branches and returns.
>> And quite contrary to Chuck Moore's approach of establishing state
>> when you start (Thinking Forth p. 212) instead of restoring it when
>> you finish that you advocated previously.
>
>Hmm. The connection with Chuck's remarks on page 212 is at most
>tenuous.
Here it is:
>Even as a programmer-only
>facility, if you're holding any locks at all you must release them
>when a thread terminates, otherwise next time you try to run your
>application it might not even start.
Same thing with BASE. So Chuck Moore's suggestion is to establish the
situation you want when you start: Release the locks.
>(And you may be halfway through
>modifying e.g. a doubly-linked list, perhaps during an ALLOCATE or a
>FREE, in which case your heap is now corrupt, etc., etc.)
I have not found a need for doubly-linked lists in 25 years, but sure,
the general problem is there. Of course, if you have a backward
branch or a return while the data structure is in an inconsistent
state, your approach is also unsafe.
>So, simply returning to QUIT doesn't do it.
In practice, it does.
>Programs acquiring locks to make sure that they do so with a CATCH
>block to release them. That's good practice anyway, of course, and
>it's no harder than
>
> disk GET ['] foo CATCH disk RELEASE throw
Good to know that you now see it as good practice, too.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-26 04:38 -0500 |
| Message-ID | <rfCdnUJGltCC6k7OnZ2dnUVZ8h6dnZ2d@supernews.com> |
| In reply to | #32654 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>> Doing it with an interrupt seems a more natural approach, if >>>>> available. >>>> >>>>Indeed it is, but you have to guarantee that at every point it's >>>>possible to abort without breaking something. >>>> >>>>As I mentioned before, I reckon the Java approach is the best I've >>>>seen: have every backward branch (except perhaps DO..LOOPs, which are >>>>hopefully finite) and every return read (or write) a magic address. >>>>When you want to interrupt a running program, read- (or write-) >>>>protect that page. From the resulting trap, THROW an exception. That >>>>way you get all locks released etc. and a nice graceful return to the >>>>outer interpreter. >>> >>> That's quite an effort. >> >>It is the simplest correct solution of which I know, which is why I >>mention it here. > > Probably. People have the choice: a simple correct solution or an even simpler incorrect one. > Hardening all the library calls against being interrupted at any > time is probably harder (depending on the amount of library stuff). In practice it's proved to be intractably difficult, which is why threads on UNIX-like systems are only cancellable at thread cancellation points. I know that Forth often goes its own way, which is good, but in this case I think the experience of other languages and systems is useful. > And then you have to take similar care for the Forth code you write; > that gets a little simpler with your approach, because the > interruption can only happen on backwards branches and returns. Right. >>> And quite contrary to Chuck Moore's approach of establishing state >>> when you start (Thinking Forth p. 212) instead of restoring it when >>> you finish that you advocated previously. >> >>Hmm. The connection with Chuck's remarks on page 212 is at most >>tenuous. > > Here it is: > >>Even as a programmer-only facility, if you're holding any locks at >>all you must release them when a thread terminates, otherwise next >>time you try to run your application it might not even start. > > Same thing with BASE. So Chuck Moore's suggestion is to establish the > situation you want when you start: Release the locks. Well, maybe it's as simple as that, maybe not. Of course you release all your own locks as part of program initialization. If you're running the entire application from scratch every time you might as well re-start the entire Forth system. More probably, though, you're just restarting a thread or just testing a single word because you don't want to restart everything. But this is the key point: in no case do you ever want to restart anything with the system or your program in an unstable state. >>(And you may be halfway through modifying e.g. a doubly-linked list, >>perhaps during an ALLOCATE or a FREE, in which case your heap is now >>corrupt, etc., etc.) > > I have not found a need for doubly-linked lists in 25 years, but sure, > the general problem is there. Well, that's all I'm saying: we don't disagree about this key point. > Of course, if you have a backward branch or a return while the data > structure is in an inconsistent state, your approach is also unsafe. Indeed, interrupting a program at arbitrary points is inherently risky, but at least the technique I'm proposing has a possibility of being correct. This is one reason why transactional memory is so attractive: a transaction either commits in a consistent state or aborts. >>Programs acquiring locks to make sure that they do so with a CATCH >>block to release them. That's good practice anyway, of course, and >>it's no harder than >> >> disk GET ['] foo CATCH disk RELEASE throw > > Good to know that you now see it as good practice, too. I don't quite understand this remark. What else would you do? If FOO can throw while holding a lock then you have to do this. The problem with asynchronous interrupts is that any word can throw, so every caller has to be aware of that. I wonder if we're really talking about different things. I'm trying to think about how asynchronous interrupts might be made robust, so that a reliable system could safely use them. But maybe it's just too much trouble: better not to allow them at all or reserve them for a programmer convenience facility and accept that the system (and your program) might be toast after being interrupted. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-07-26 15:56 +0200 |
| Message-ID | <lr0c27$lfa$1@online.de> |
| In reply to | #32685 |
Andrew Haley wrote:
>>> disk GET ['] foo CATCH disk RELEASE throw
>>
>> Good to know that you now see it as good practice, too.
>
> I don't quite understand this remark. What else would you do? If FOO
> can throw while holding a lock then you have to do this. The problem
> with asynchronous interrupts is that any word can throw, so every
> caller has to be aware of that.
That's why Gforth's pthread-based multitasker has a C-SECTION word, which
takes an xt and a lock, and does essentially both those things.
: c-section ( xt addr -- )
\G implement a critical section that will unlock the semaphore
\G even in case there's an exception within.
{ sema } try sema lock execute 0 restore sema unlock endtry throw ;
You better do that anyways, because if you make a mistake, it will throw,
too. The problem with this approach and standard Forth is that if you ctrl-
C between catch and the successful unlock, you'll get thrown out. That's
why Gforth has try/restore/endtry, here the restore part is performed before
unwinding the exception handler, so any ctrl-C between restore and entry
will jump to the restore label again. As the exception frame is on the
return stack, I put the semaphore address on the locals stack to avoid
conflicts.
> I wonder if we're really talking about different things. I'm trying
> to think about how asynchronous interrupts might be made robust, so
> that a reliable system could safely use them. But maybe it's just too
> much trouble: better not to allow them at all or reserve them for a
> programmer convenience facility and accept that the system (and your
> program) might be toast after being interrupted.
From my experience, it doesn't make sense to have ctrl-C interrupt a
background threads. Therefore, I simply block all asynchronous exceptions
on all background threads - the one single foreground thread will receive
them. If your background thread gets stuck, you still can get to an
interactive command line and kill those background tasks.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-27 13:27 +0000 |
| Message-ID | <2014Jul27.152730@mips.complang.tuwien.ac.at> |
| In reply to | #32685 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> And then you have to take similar care for the Forth code you write;
>> that gets a little simpler with your approach, because the
>> interruption can only happen on backwards branches and returns.
>
>Right.
I am not convinced that doing it on returns is a good idea for Forth,
though. It means that you are limited in the use of colon definitions
when restoring state. Also, the run-time routine of EXIT/; is one of
the most frequent primitives in Forth (12%-16% of all dynamically
executed primitives). I guess the goal in Java is to make
long-running recursive methods (without loops) interruptible. I think
a better way for Forth is to check on RECURSE, EXECUTE, and when
calling DEFERred words.
>This is one reason why transactional memory is so attractive: a
>transaction either commits in a consistent state or aborts.
And it also works with multi-threaded programs, not just asynchronous
THROWs. But the expense...
>>>Programs acquiring locks to make sure that they do so with a CATCH
>>>block to release them. That's good practice anyway, of course, and
>>>it's no harder than
>>>
>>> disk GET ['] foo CATCH disk RELEASE throw
>>
>> Good to know that you now see it as good practice, too.
>
>I don't quite understand this remark.
When I posted similar code, you claimed it was "gross overkill"
<12rkb5mellfeo14@news.supernews.com>, and quoted Chuck Moore from page
212 of Thinking Forth (2004 edition).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-27 09:36 -0500 |
| Message-ID | <SNudnQQC_Ifqk0jOnZ2dnUVZ_oSdnZ2d@supernews.com> |
| In reply to | #32714 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> And then you have to take similar care for the Forth code you write; >>> that gets a little simpler with your approach, because the >>> interruption can only happen on backwards branches and returns. >> >>Right. > > I am not convinced that doing it on returns is a good idea for Forth, > though. It means that you are limited in the use of colon definitions > when restoring state. Also, the run-time routine of EXIT/; is one of > the most frequent primitives in Forth (12%-16% of all dynamically > executed primitives). I guess the goal in Java is to make > long-running recursive methods (without loops) interruptible. I think > a better way for Forth is to check on RECURSE, EXECUTE, and when > calling DEFERred words. Perhaps so, yes. It doesn't hurt much in the HotSpot Java VM because it typically inlines a lot. >>This is one reason why transactional memory is so attractive: a >>transaction either commits in a consistent state or aborts. > > And it also works with multi-threaded programs, not just asynchronous > THROWs. But the expense... That's fair. >>>>Programs acquiring locks to make sure that they do so with a CATCH >>>>block to release them. That's good practice anyway, of course, and >>>>it's no harder than >>>> >>>> disk GET ['] foo CATCH disk RELEASE throw >>> >>> Good to know that you now see it as good practice, too. >> >>I don't quite understand this remark. > > When I posted similar code, you claimed it was "gross overkill" > <12rkb5mellfeo14@news.supernews.com>, and quoted Chuck Moore from page > 212 of Thinking Forth (2004 edition). But that was manipulating BASE, not undoing a lock. Is that really similar? I suppose it could be, but my personal preference has always been to set BASE where it's needed rather than setting it and assuming that it'll stick. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-28 11:38 +0000 |
| Message-ID | <2014Jul28.133853@mips.complang.tuwien.ac.at> |
| In reply to | #32716 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>Programs acquiring locks to make sure that they do so with a CATCH
>>>>>block to release them. That's good practice anyway, of course, and
>>>>>it's no harder than
>>>>>
>>>>> disk GET ['] foo CATCH disk RELEASE throw
>>>>
>>>> Good to know that you now see it as good practice, too.
>>>
>>>I don't quite understand this remark.
>>
>> When I posted similar code, you claimed it was "gross overkill"
>> <12rkb5mellfeo14@news.supernews.com>, and quoted Chuck Moore from page
>> 212 of Thinking Forth (2004 edition).
>
>But that was manipulating BASE, not undoing a lock. Is that really
>similar? I suppose it could be, but my personal preference has always
>been to set BASE where it's needed rather than setting it and assuming
>that it'll stick.
So why don't you make it your personal preference to release locks
where it's needed?
In general, "setting BASE where it's needed" is not practical. Just
consider Chuck Moore's example: He has a BASE-less dump, so he can do
a HEX DUMP or a DECIMAL DUMP. Now what if I want the addresses in
hex, and the rest in the BASE that was set before DUMP (as Chuck Moore
did in his example)? "Setting BASE where it's needed" does not cut
it.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-28 10:42 -0500 |
| Message-ID | <7P-dnV47LPDL8kvOnZ2dnUVZ_uWdnZ2d@supernews.com> |
| In reply to | #32727 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>>>Programs acquiring locks to make sure that they do so with a CATCH >>>>>>block to release them. That's good practice anyway, of course, and >>>>>>it's no harder than >>>>>> >>>>>> disk GET ['] foo CATCH disk RELEASE throw >>>>> >>>>> Good to know that you now see it as good practice, too. >>>> >>>>I don't quite understand this remark. >>> >>> When I posted similar code, you claimed it was "gross overkill" >>> <12rkb5mellfeo14@news.supernews.com>, and quoted Chuck Moore from page >>> 212 of Thinking Forth (2004 edition). >> >>But that was manipulating BASE, not undoing a lock. Is that really >>similar? I suppose it could be, but my personal preference has always >>been to set BASE where it's needed rather than setting it and assuming >>that it'll stick. > > So why don't you make it your personal preference to release locks > where it's needed? I do: locks have to be released in a structured way, at the same level they're locked, preferably in the same word. That's the nature of a lock. I have seen code that uses unstructured locking, and IME usually that's a bug. > In general, "setting BASE where it's needed" is not practical. Just > consider Chuck Moore's example: He has a BASE-less dump, so he can > do a HEX DUMP or a DECIMAL DUMP. Now what if I want the addresses > in hex, and the rest in the BASE that was set before DUMP (as Chuck > Moore did in his example)? Err, you change DUMP to fit your needs. "In general", jumping to ABORT and resetting a few in response to an interrupt things doesn't work either, but maybe most of the time it works well enough for your needs. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-07-25 16:56 -0400 |
| Message-ID | <op.xjkm37hk6zenlw@localhost> |
| In reply to | #32646 |
On Fri, 25 Jul 2014 10:21:01 -0400, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> bruce.mcfarling wrote: >>>> Doing it with an interrupt seems a more natural approach, if >>>> available. >>> >>> Indeed it is, but you have to guarantee that at every point it's >>> possible to abort without breaking something. >> >> That's quite an effort. > > It is the simplest correct solution of which I know, which is why I > mention it here. In general, asynchronous exceptions are a hard > problem. > Um... Why isn't the host OS for SwiftForth sending a signal to the main Forth app upon receiving a Ctrl-C, Ctrl-Break, etc? Shouldn't the host OS be doing so? ... SwiftForth should only be getting keyboard input after it has been processed by the host OS. SwiftForth shouldn't be reading the hardware directly. I.e., offhand, I would guess that SwiftForth is ignoring or blocking something. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-26 09:33 +0000 |
| Message-ID | <FcudnZD4rv986E7OnZ2dnUVZ_t-dnZ2d@supernews.com> |
| In reply to | #32659 |
On 7/25/14 8:56 PM, Rod Pemberton wrote: > On Fri, 25 Jul 2014 10:21:01 -0400, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>> bruce.mcfarling wrote: > >>>>> Doing it with an interrupt seems a more natural approach, if >>>>> available. >>>> >>>> Indeed it is, but you have to guarantee that at every point it's >>>> possible to abort without breaking something. >>> >>> That's quite an effort. >> >> It is the simplest correct solution of which I know, which is why I >> mention it here. In general, asynchronous exceptions are a hard >> problem. >> > > Um... > > Why isn't the host OS for SwiftForth sending a signal to the main > Forth app upon receiving a Ctrl-C, Ctrl-Break, etc? > > Shouldn't the host OS be doing so? ... The Linux/OSX SwiftForth does this, and Ctrl-C works fine. I don't know why the Windows version doesn't, and cannot investigate now. That's why I suggested Jason ask FORTH, Inc. > SwiftForth should only be getting keyboard input after it has > been processed by the host OS. SwiftForth shouldn't be reading > the hardware directly. Yes, that's how it works on hosted systems. > I.e., offhand, I would guess that SwiftForth is ignoring > or blocking something. The Windows SwiftForth is very complicated, as is necessary when dealing with Windows. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-07-24 19:40 -0400 |
| Message-ID | <lqs5ht$vcf$1@dont-email.me> |
| In reply to | #32625 |
On 7/24/2014 11:52 AM, bruce.mcfarling@gmail.com wrote: > On Thursday, July 24, 2014 10:39:21 AM UTC-4, rickman wrote: >> You don't need to check at every semi do you? I think once around the >> loop is enough. The semi is used greatly and adding any code to that >> would slow down the process. Adding it to the looping words would not >> have as much impact. > > Checking it in BRANCH and ?BRANCH (or whatever the branching operations that implement the loops are called in the implementation at hand) might be more often than checking it at SEMI if there are nothing but primitives in the loop ... but BRANCH and ?BRANCH would be the place to check it if you wanted to go that route, as that is precisely where you can get caught in an endless loop. > > Doing it with an interrupt seems a more natural approach, if available. Doing what with an interrupt? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-25 00:00 +0000 |
| Message-ID | <53d19e16$0$15870$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32629 |
In article <lqs5ht$vcf$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 7/24/2014 11:52 AM, bruce.mcfarling@gmail.com wrote: >> On Thursday, July 24, 2014 10:39:21 AM UTC-4, rickman wrote: >>> You don't need to check at every semi do you? I think once around the >>> loop is enough. The semi is used greatly and adding any code to that >>> would slow down the process. Adding it to the looping words would not >>> have as much impact. >> >> Checking it in BRANCH and ?BRANCH (or whatever the branching operations that >implement the loops are called in the implementation at hand) might be more often than >checking it at SEMI if there are nothing but primitives in the loop ... but BRANCH and >?BRANCH would be the place to check it if you wanted to go that route, as that is >precisely where you can get caught in an endless loop. >> >> Doing it with an interrupt seems a more natural approach, if available. > >Doing what with an interrupt? Interrupting the program. Didn't you notice what we were trying to do? > >-- > >Rick Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-07-24 22:17 -0400 |
| Message-ID | <lqsen7$f80$1@dont-email.me> |
| In reply to | #32630 |
On 7/24/2014 8:00 PM, Albert van der Horst wrote: > In article <lqs5ht$vcf$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> On 7/24/2014 11:52 AM, bruce.mcfarling@gmail.com wrote: >>> On Thursday, July 24, 2014 10:39:21 AM UTC-4, rickman wrote: >>>> You don't need to check at every semi do you? I think once around the >>>> loop is enough. The semi is used greatly and adding any code to that >>>> would slow down the process. Adding it to the looping words would not >>>> have as much impact. >>> >>> Checking it in BRANCH and ?BRANCH (or whatever the branching operations that >> implement the loops are called in the implementation at hand) might be more often than >> checking it at SEMI if there are nothing but primitives in the loop ... but BRANCH and >> ?BRANCH would be the place to check it if you wanted to go that route, as that is >> precisely where you can get caught in an endless loop. >>> >>> Doing it with an interrupt seems a more natural approach, if available. >> >> Doing what with an interrupt? > > Interrupting the program. > Didn't you notice what we were trying to do? Your writing is not clear. The interrupt is a separate process. The interrupt then has to do something to alter the flow of the program. Just saying "do it with an interrupt" doesn't explain anything. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-25 06:54 -0700 |
| Message-ID | <9b1cf98e-2dbb-4ea6-b326-585c58904bf3@googlegroups.com> |
| In reply to | #32629 |
On Thursday, July 24, 2014 7:40:33 PM UTC-4, rickman wrote: > On 7/24/2014 11:52 AM, BruceMcF wrote: >> On Thursday, July 24, 2014 10:39:21 AM UTC-4, rickman wrote: >>> You don't need to check at every semi do you? I think once around the >>> loop is enough. The semi is used greatly and adding any code to that >>> would slow down the process. Adding it to the looping words would not >>> have as much impact. >> >> Checking it in BRANCH and ?BRANCH (or whatever the branching operations that implement the loops are called in the implementation at hand) might be more often than checking it at SEMI if there are nothing but primitives in the loop ... but BRANCH and ?BRANCH would be the place to check it if you wanted to go that route, as that is precisely where you can get caught in an endless loop. >> >> Doing it with an interrupt seems a more natural approach, if available. > > Doing what with an interrupt? What the OP asked about ~ allowing a user to break a program from the keyboard.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web