>>>>> "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
CF> Please explain how any of this will make signals safer? Safer
CF> signals is a core issue. Not a language issue. Whatever mechanism
CF> you select it will not make signals safer.
then tell me how you request delivery of a safe signal without any
language hooks? the delivery must be controlled by the program, hence it
has to have language to access that control.
CF> This is appropriate here in -language(-flow) if you want to change
CF> the user level interface. Otherwise, it belongs in -core.
it affect both levels. as i have stated, i want to explain the reasons
for the language changes and to show a path for how it can be
implemented. and also showing how the signal delivery would interact
with other flow control areas.
the mailbox thing is a language issue. so is the pragma that tells perl
how to deliver signals, via op code check every N ops or via a mailbox
or via event loops. since perl is interpeted and signals are
asynchronous with regard to that interpreter, there has to be a code
level method of describing the method of synchronization. the only
alternative is forcing the insertion of signal checking op codes. and no
one wants that.
CF> Perhaps this RFC should simply be renamed. "New singal handling
CF> metaphor" or whatever.
i disagree. it is a language issue and then it will evolve into an
internals issue.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
