Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Wed, 3 Sep 2003, Leopold Toetsch wrote:
>
> >> Then we might get deadlocks.
>
> > This is always a possibility, and there isn't anything we
> > can do about it at the interpreter level. Deadlocks are
> > an unfortunate fact
in following the threads on traversing pmc trees, we seem to have
reached a deadlock (pun intended). deadlock detection is a pain as most
db designers have found. they don't dare to db level locking for fear of
slowdowns. dbs are always modifying rows and tables so fine grained
locking is imperati
On Wed, 3 Sep 2003, Brent Dax wrote:
> Dan Sugalski:
> # It's impossible to have clone in a threaded environment guarantee that
> it
> # won't deadlock.
>
> If I recall correctly, all shared variables are owned by a single shared
> interpreter.
Nope. Shared variables are owned by their creating
Dan Sugalski:
# It's impossible to have clone in a threaded environment guarantee that
it
# won't deadlock.
If I recall correctly, all shared variables are owned by a single shared
interpreter. What if, the first time the traversal encounters a shared
PMC, it gets a lock on the shared interpreter
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Wed, 3 Sep 2003, Leopold Toetsch wrote:
>
> >> Then we might get deadlocks.
>
> > This is always a possibility, and there isn't anything we can do about it
> > at the interpreter level. Deadlocks are an u
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Sep 2003, Leopold Toetsch wrote:
>> Then we might get deadlocks.
> This is always a possibility, and there isn't anything we can do about it
> at the interpreter level. Deadlocks are an unfortunate fact of life in a
> threaded environment.
clon
On Wed, Sep 03, 2003 at 02:07:10PM -0400, Dan Sugalski wrote:
> On Wed, 3 Sep 2003, Leopold Toetsch wrote:
>
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > On Wed, 3 Sep 2003, Leopold Toetsch wrote:
> >
> > >> But if one thread sets pmc->next_for_GC the next thread might encounter
> > >> this
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Wed, 3 Sep 2003, Leopold Toetsch wrote:
>
> >> But if one thread sets pmc->next_for_GC the next thread might encounter
> >> this PMC later (albeit for this thread at the first time) and think, I've
> >> vi
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Sep 2003, Leopold Toetsch wrote:
>> But if one thread sets pmc->next_for_GC the next thread might encounter
>> this PMC later (albeit for this thread at the first time) and think, I've
>> visited this PMC already and just flush out the object ID
"Burnett, David" <[EMAIL PROTECTED]> writes:
> I asked how to 'floor' in parrot on IRC last night, and this raised the
> the idea of having a 'floor' op. I was then asked to email a reminder here
> so here it is.
I've implemented an op for floor on native numbers. Feel free to give
it a whirl.
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
> K Stol <[EMAIL PROTECTED]> wrote:
>
> > just a thought: aren't shared objects/data/whatever protected by a
> > mutex? To me, that's the obvious solution for accessing shared data.
> > As I said, just a thought.
>
> They will be protected by a mutex ye
K Stol <[EMAIL PROTECTED]> wrote:
> just a thought: aren't shared objects/data/whatever protected by a
> mutex? To me, that's the obvious solution for accessing shared data.
> As I said, just a thought.
They will be protected by a mutex yes. That helps against two threads
updating the same PMC at
- Original Message -
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
To: "Peter Haworth" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, September 03, 2003 4:38 PM
Subject: Re: [RfC] vtable->dump
> Peter Haworth <[EMAIL PROTECTED]> wrote:
> > On Wed, 3 Sep 2003 09:24:22 +0200, L
Peter Haworth <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Sep 2003 09:24:22 +0200, Leopold Toetsch wrote:
>> One general traverse() vtable is just the simpler interface IMHO.
>>
>> Running through each aggregate just once plus updating a seen_hash seems
>> simpler and faster to me and doesn't have any n
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
> Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > I don't know why this didn't show up anywhere else, but on Solaris 8 with
> > perl5.00503, the imcc/t/syn/file.t tests that tried to load temp.pbc were
> > all failing. The reason turned out to be that the
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> I'm looking for, but not finding, information regarding the character
> type and encoding on parrot io objects.
>
> As an example of why... I found this in io.ops :
>
> op write(in PMC) {
> PMC *p = $1;
> STRING *s = (VTABLE_get_string(interpre
On Wed, 3 Sep 2003 09:24:22 +0200, Leopold Toetsch wrote:
> One general traverse() vtable is just the simpler interface IMHO.
>
> Running through each aggregate just once plus updating a seen_hash seems
> simpler and faster to me and doesn't have any negative impact on PMC size
> and DOD speed.
An
I asked how to 'floor' in parrot on IRC last night, and this raised the
the idea of having a 'floor' op. I was then asked to email a reminder here
so here it is.
I have worked around the lack of rounding by dubiously using
mod N1, N0, 1
sub N0, N1
which appears to be more acurrate than simply
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> I don't know why this didn't show up anywhere else, but on Solaris 8 with
> perl5.00503, the imcc/t/syn/file.t tests that tried to load temp.pbc were
> all failing. The reason turned out to be that the temp.imc files hadn't
> been flushed to disk yet. E
On Wed, 3 Sep 2003, Bernhard Schmalhofer wrote:
> Amir Karger wrote:
> > A couple more questions on the coding front:
> >
> > (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I
> > steal code or ideas from there, does Parrot or this piece of it have to
> > be GPL only instead of
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:38 PM +0200 9/2/03, Leopold Toetsch wrote:
[ next_for_GC ]
> That's easy, then, as it is. :) Besides, from looking at pobj.h, it's
> already there, so I'm not sure what we'd need to do. Perhaps I need
> to resync.
The PMC_EXT structure is only alloca
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
[ optimize DOD before thaw/clone ]
> Even with a depth restriction, a recursive estimate can produce
> misleading results due to circular references. Only actually walking
> the structure can get the number right. However, wa
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> As an example of why... I found this in io.ops :
> op write(in PMC) {
Sorry for that. This was a quick hack, to get
languages/parrot_compiler/parrot_pasm working again. As you mentioned
below, there was no print routine that transparently handled bi
Amir Karger <[EMAIL PROTECTED]> wrote:
> A couple more questions on the coding front:
> (1) Even though it's supposed to be "native" Parrot support, I'm still
> allowed to write in PIR, right? Because that'll be translated to pasm
> and thereby be native.
You should target PIR. PIR is "native" pa
Amir Karger wrote:
A couple more questions on the coding front:
(2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I
steal code or ideas from there, does Parrot or this piece of it have to
be GPL only instead of GPL/Artistic? I am happily ignorant about
licensing issues.
Hi,
I have
25 matches
Mail list logo
