>>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> Otherwise, programmers will forever be guessing (wrong) about what
PRL> exactly they can rely on the interpreter for.
PRL> This RFC proposes that the boundary be placed at I<data coherence>.
PRL> Data coherence means that primitive operations in Perl always produce
PRL> a result that could be obtained if the operation executed atomically.
Make that each thread executed in serial order. _AS IF_ they were not
interleaved.
PRL> Under RFC178, any data value may be shared between threads. The simple
PRL> way to ensure synchronized access to all data values is to give each
PRL> one a mutex.
And how do you propose to make up performance with your mutex grab and
unlock on each and every value accessed vs. The isolation model?
PRL> I think there are enough unknowns in all this that it is premature to
PRL> withdraw RFC178 on implementation or performance grounds.
Actually a simple count of mutex grabs and releases should be sufficient
to start this with a large deficit.
PRL> I prefer a shared data model because
PRL> It does what I want.
Are you really planning on sharing _every_ variable between _all_
threads? Come now, if you are really doing that, you are giving up
a huge amount of performance on handshaking.
As a practical matter only some small number of variables are really
needed for inter-thread communication.
PRL> The collection of Perl5 modules that an isolated data model can rescue
PRL> from reentrancy problems may be vanishingly small; conversely, it may
PRL> break modules that genuinely need global data.
The isolation model for modules has another win, even without threads.
Module A's use of B may have nasty interactions with C's use of B.
PRL> =item C<Sys::Hostname>
PRL> C<Sys::Hostname> gets the system hostname and caches it in
PRL> C<$Sys::Hostname::host>. This works correctly in a shared data model,
PRL> even without any synchronization mechanism. An isolated data model
PRL> defeats the cache, forcing every thread to look up the hostname
PRL> itself.
So what. That's a performance issue, not a correctness issue. We are
concerned with correctness. Performance would require a rewrite.
PRL> C<File::Find> stores the name of the current file in
PRL> C<$File::Find::name>, and the current directory path in
PRL> C<$File::Find::path>. This works in an isolated data model, and breaks
PRL> in a shared data model.
PRL> However, C<File::Find> also C<cd>s to the directory where the current
PRL> file is. This isn't reentrant, and it can't be made reentrant, because
PRL> a process has only one CWD, which is shared by all threads. This means
PRL> that the C<File::Find> interface is intrinsically broken under
PRL> threads.
Not really, what if two threads need different current directories?
Same problem, you are just pointing the finger.
The others are 'broken' even without threads. They are not usable
recursively.
Threads, just excerbiate the problems.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
