Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #19475
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Forced exit from an infinite loop? (Win32Forth / eForth) |
| Date | 2013-02-05 15:26 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2013Feb5.162623@mips.complang.tuwien.ac.at> (permalink) |
| References | <2013Feb4.171158@mips.complang.tuwien.ac.at> <08b7f96d-f522-4b7b-87e9-109c92e06597@googlegroups.com> <510fc304$0$618$e4fe514c@dreader34.news.xs4all.nl> <20130204170005.4073.23575@Nokia-N810-43-7> |
Andy Valencia <user@vsta.org> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> ... there is a standard
>> throw code for "User Interrupt", which I take as a suggestion that a
>> full-featured system should turn a user interrupt (SIGINT in a POSIX
>> system, generated by Ctrl-C at a normally configured terminal) into
>> this Forth exception and let the Forth system deal with it; and if the
>> exception is not caught by the application, the Forth system should
>> print an appropriate message and continue in the Forth command line,
>
>The classic problem is somebody interrupts during compilation, and the
>system's updating something critical like the word dictionary when you jump
>back out to the prompt. So you (the Forth implementer) need to identify
>critical sections in your code to make sure such sections complete before
>dispatching the asynchronous event. Typically in C based Forth's the rule is
>that everything involving critical sections is written in C, and Forth
>interpreter interrupts only happen when you get back to the Forth level.
Gforth does not do this kind of protection, and since it is more
protective than most, I doubt that others do it, either.
However, we do a different kind of protection. In many cases, we
CATCH the exception if it could lead to problems (e.g., if there is a
temporary change of global state, e.g., of BASE) and perform the
appropriate recovery action (e.g., restoring BASE to the previous
value) before THROWing the exception onwards.
In other cases, the problem can often be avoided by having a
committing store. E.g., for the problem you mention of defining a
word in the dictionary, one can perform the REVEAL at the end (hmm,
looking at CREATE, this does not happen for CREATE, CONSTANT and
VALUE; it does for ";", though).
REVEAL itself deals with linked lists, where it is easy to commit the
insertion of a new element with a single "!"; there are two potential
problems in connection with hash tables, though:
1) Each word is inserted in two linked lists, so it might end up on
one list, but not on the other. This would be confusing, because the
hash-table linked list is used for searching, while the classical
Forth linked list is used by WORDS. Also, after later rehashing, the
word might appear in the hash table or disappear from it (but the
state would be consistent then).
2) It's not clear to me what happens if an exception occurs during
rehashing, probably an incomplete hash-table. Should be easy to spot,
though.
Oh, BTW, these things are all on the Forth level, so delaying
exceptions until the Forth level would not help (and would be a pretty
expensive feature).
Despite having less protection against such things than would be
relatively easily possible, I have not yet experienced such problems
nor heard about them. Given that one can easily have system
corruption from, say, a buggy use of "!", Forth users should be
prepared to restart the system when things look fishy, and investing a
lot of work into proofing it against the kinds of effects you pointed
out is probably not a good use of resources.
- 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 2013: http://www.euroforth.org/ef13/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Forced exit from an infinite loop? (Win32Forth / eForth) AKE <assadebrahim2000@gmail.com> - 2013-02-04 04:36 -0800
Re: Forced exit from an infinite loop? (Win32Forth / eForth) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-04 14:17 +0000
Re: Forced exit from an infinite loop? (Win32Forth / eForth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-04 16:11 +0000
Re: Forced exit from an infinite loop? (Win32Forth / eForth) Andy Valencia <user@vsta.org> - 2013-02-04 17:06 +0000
Re: Forced exit from an infinite loop? (Win32Forth / eForth) Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-04 19:53 +0100
Re: Forced exit from an infinite loop? (Win32Forth / eForth) Andy Valencia <user@vsta.org> - 2013-02-05 01:00 +0000
Re: Forced exit from an infinite loop? (Win32Forth / eForth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-05 15:26 +0000
Re: Forced exit from an infinite loop? (Win32Forth / eForth) Mark Wills <forthfreak@gmail.com> - 2013-02-04 07:32 -0800
Re: Forced exit from an infinite loop? (Win32Forth / eForth) Coos Haak <chforth@hccnet.nl> - 2013-02-04 21:05 +0100
Re: Forced exit from an infinite loop? (Win32Forth / eForth) Alex McDonald <blog@rivadpm.com> - 2013-02-04 12:32 -0800
Re: Forced exit from an infinite loop? (Win32Forth / eForth) "Elizabeth D. Rather" <erather@forth.com> - 2013-02-04 11:24 -1000
Re: Forced exit from an infinite loop? (Win32Forth / eForth) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-05 18:01 +0000
Re: Forced exit from an infinite loop? (Win32Forth / eForth) "Ed" <invalid@nospam.com> - 2013-02-05 10:44 +1100
Re: Forced exit from an infinite loop? (Win32Forth / eForth) Mark Wills <forthfreak@gmail.com> - 2013-02-04 23:09 -0800
Re: Forced exit from an infinite loop? (Win32Forth / eForth) AKE <assadebrahim2000@gmail.com> - 2013-02-05 05:06 -0800
csiph-web