>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> No, not really. The big reasons I wasn't planning on unification are:
DS> *) It makes the amount of mental space the core interpreter takes
DS> up smaller
not if the regex ops were developed separately. all it will do is expand
the op table, not make the core more complex. also the regex compiler
can be written separately as well.
DS> *) It can make performance tradeoffs separately from the main perl engine
that can be done with a regex optimizer, or creating more specialized
and efficient regex ops.
DS> *) We can probably snag the current perl 5 source without much change
is that worth keeping? maybe for bootstrapping the new setup but not
permanently. stuff like having direct access to regex engine for
debugging would be better designed in from scratch. and the moving of
the engine to the main op code loop solves that problem.
DS> *) Treating regexes as non-atomic operations brings some serious
DS> threading issues into things.
well, the main op loop is threaded (isn't one of the bugs with current
threads the fact that the regex engine is not thread safe?) so you get
that automatically. by just marking the regex data as shared should
trigger all the right thread locks and stuff. what happens to $1 when
the data is shared and threaded? are thread local copies of the original
data made and $1 maps inside those?
>> That's a scenario I'd love to avoid. And if we can manage to store
>> regex opcodes and state using mechanisms similar to ordinary opcodes,
>> maybe we'll not fall back into the situation where the regex engine is
>> understood by only three people, plus or minus four.
DS> While I'm not sure I agree with it, if that's what you want, then that's
DS> what we'll do. Threading will complicate this some, since we'll need to
DS> guarantee atomicity across multiple opcodes, something I'd not planned on
DS> doing.
what is wrong with a single mutex (or equivilent) around the regex? that
is a simple way to gain atomicity over multiple ops. and we would have
to define what is atomic in detail. most regexes will operate on thread
specific data as most data should be thread specific. doing a regex on a
shared variable may be costly but that can be dealt with by copying it
first to a thread local variable.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
