Re: A question of programming technique in C

[Richard Harter]

On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@sun.comwrote:

>Richard Harter wrote:

>Suppose we are writing a program in C and that we have a
particular kind of object (in the sense of OO programming) that I
will call bobbles. Being well disciplined programmers (Ha!) we
create a module to package our bobble related functions together.

If we were using an OO based language there would be machinery in
place, constructors, destructors, and such like, to handle the
details of our module, but in C we have to roll our own.

One of the things we need to do is to create functions that will
serve as constructors and destructors. There are two things that
we have to take care of, specifying the interface, and writing
the function internals. My concern is with specifying the
interface.

I am going to throw in one curve ball. Our program will contain
references to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.

As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. Your issues appear to deal with
representation hiding and validity checking, not with garbage
collection.

I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:

At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.

At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.

At time C we delete bobble X. All space is deallocated.

At time D we allocate bobble Y. As it chances, Y has the same
address as X.

At time E the program attempts to peform the scheduled operation
on X. It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.

Simply hashing the address into an integer won't work because the
addresses are the same. Likewise using an opaque pointer doesn't
work. That's the point of the "unique id" - it is different for
different bobbles even though they have the same address.

Of course you can use sequence numbers as keys in a hash table or
some kind of search tree, but that is relatively computationally
expensive compared to the descriptor/locator paired structs.


Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Pierre Asselin]

In comp.lang.c Richard Harter <cr*@tiac.netwrote:

[ ... ]
At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.

Put a unique "serial number" in each bobble. At creation time,
initialize the serial number from an incremented global counter.
Before deletion, set it to zero. Don't free() your deleted bobbles,
put them on a free list and get new storage from that list before
you fall back on malloc(). This is to ensure that serial numbers
are either zero or unique, and never garbage.

At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.

In your queued request, store a copy of the serial number as well as
a pointer to X.

At time C we delete bobble X. All space is deallocated.

At time D we allocate bobble Y. As it chances, Y has the same
address as X.

Y gets a brand new serial number.

At time E the program attempts to peform the scheduled operation
on X. It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.

Check that the serial number matches the copy on the request.
If not, well only you know what to do. Cancel the request
or report an error, whatever applies to your situation.

Don't let the global counter overflow. Follow your creation
and destruction discipline meticulously. This is C, the language
won't call destructors for you.

--
pa at panix dot com

[Eric Sosman]

Richard Harter wrote:

On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@sun.comwrote:

>Richard Harter wrote:

>>>[...]
I am going to throw in one curve ball. Our program will contain
references to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.

As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. Your issues appear to deal with
representation hiding and validity checking, not with garbage
collection.

I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:

At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.

At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.

At time C we delete bobble X. All space is deallocated.

If zeta is still armed and dangerous, this seems to me to
be an error in the program and not something a bobblefeature
should be expected to deal with. You're asking a destroyed
bobble to "remember" its former existence somehow, so it can
still respond in some way to an attempt to do something with
its non-existent self ... It doesn't seem to me that a robust
programming discipline should rely on spirit messages from the
afterlife.

If you're like me, your feet have occasionally taken one
more step than there were stairs. I've never thought that it
was the stairway's job to detect my misstep and protect me
somehow (by deploying a padded cell, perhaps?), especially
if the stairway itself has been demolished.

Or, as an instructor once told me, "Don't Do That."

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Richard Harter]

On Wed, 5 Nov 2008 02:55:29 +0000 (UTC), [e-mail]
(Pierre Asselin) wrote:

>In comp.lang.c Richard Harter <cr*@tiac.netwrote:

>[ ... ]
At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.

Put a unique "serial number" in each bobble. At creation time,
initialize the serial number from an incremented global counter.
Before deletion, set it to zero. Don't free() your deleted bobbles,
put them on a free list and get new storage from that list before
you fall back on malloc(). This is to ensure that serial numbers
are either zero or unique, and never garbage.

>At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.

In your queued request, store a copy of the serial number as well as
a pointer to X.

>At time C we delete bobble X. All space is deallocated.

>At time D we allocate bobble Y. As it chances, Y has the same
address as X.

Y gets a brand new serial number.

>At time E the program attempts to peform the scheduled operation
on X. It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.

Check that the serial number matches the copy on the request.
If not, well only you know what to do. Cancel the request
or report an error, whatever applies to your situation.

Don't let the global counter overflow. Follow your creation
and destruction discipline meticulously. This is C, the language
won't call destructors for you.

Er, the serial number approach was part of the original proposal.
Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Richard Harter]

On Tue, 04 Nov 2008 22:34:53 -0500, Eric Sosman
<es*****@ieee-dot-org.invalidwrote:

>Richard Harter wrote:

>On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@sun.comwrote:

>>Richard Harter wrote:
[...]
I am going to throw in one curve ball. Our program will contain
references to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.
As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. Your issues appear to deal with
representation hiding and validity checking, not with garbage
collection.

I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:

At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.

At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.

At time C we delete bobble X. All space is deallocated.

If zeta is still armed and dangerous, this seems to me to
be an error in the program, and not something a bobblefeature
should be expected to deal with. You're asking a destroyed
bobble to "remember" its former existence somehow, so it can
still respond in some way to an attempt to do something with
its non-existent self ... It doesn't seem to me that a robust
programming discipline should rely on spirit messages from the
afterlife.

If you're like me, your feet have occasionally taken one
more step than there were stairs. I've never thought that it
was the stairway's job to detect my misstep and protect me
somehow (by deploying a padded cell, perhaps?), especially
if the stairway itself has been demolished.

Or, as an instructor once told me, "Don't Do That."

You're misreading the situation. I'm not asking the destroyed
bobble to "remember" anything. How can it, when it no longer
exists? What I proposed was that zeta be able to detect the
non-existence of X when its time came. The technique I proposed
does require that the "locator" struct remain in existence; zeta
detects the non-existence of X by the mismatch of serial numbers.
However I don't see that as an onerous requirement.

Perhaps more importantly, I completely disagree with your view
that "If zeta is still armed and dangerous, this seems to me to
be an error in the program." Au contraire, in the situations I
am interested in it is an essential capability. As an example
think about a printer and the printer software. The printer
software is supposed to be able to deal with the fact that the
printer may be off line.
Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Megalo]

"Richard Harter" <cr*@tiac.netha scritto nel messaggio
news:49****************@news.sbtc.net...

On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@sun.comwrote:
At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.

if *X=={u32, u32, u32}

we create a name string X@Point@32@32@32 a pointer allocated
and the memory space

X is
{u32* pointer=Space==32*3 bits /* space to point
u32* name ="X@Point@32@32@32" /* type to point
}

evalutation X return X->pointer
evalutation type use return X->"Point@32@32@32"
evalutation name X->"X"

At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.

At time C we delete bobble X. All space is deallocated.

X is
{u32* pointer=0
u32* name ="X@Point@0"
}

At time D we allocate bobble Y. As it chances, Y has the same
address as X.

Y is
{u32* pointer=Space==32*3 bits
u32* name ="Y@Point@32@32@32"
}

At time E the program attempts to peform the scheduled operation
on X. It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.

see the actual X
X is
{u32* pointer->0
u32* name ->X@Point@0
}

Simply hashing the address into an integer won't work because the
addresses are the same. Likewise using an opaque pointer doesn't
work. That's the point of the "unique id" - it is different for
different bobbles even though they have the same address.

Of course you can use sequence numbers as keys in a hash table or
some kind of search tree, but that is relatively computationally
expensive compared to the descriptor/locator paired structs.


Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Nick Keighley]

On 5 Nov, 00:22, [e-mail] (Richard Harter) wrote:

On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<[e-mail]:

Richard Harter wrote:

Suppose we are writing a program in C and that we have a
particular kind of object (in the sense of OO programming) that I
will call bobbles. *Being well disciplined programmers (Ha!) we
create a module to package our bobble related functions together.

If we were using an OO based language there would be machinery in
place, constructors, destructors, and such like, to handle the
details of our module, but in C we have to roll our own.

One of the things we need to do is to create functions that will
serve as constructors and destructors. *There are two things that
we have to take care of, specifying the interface, and writing
the function internals. *My concern is with specifying the
interface.

I am going to throw in one curve ball. *Our program will contain
references to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. *The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.

* * As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. *Your issues appear to deal with
representation hiding and validity checking, not with garbage
collection.

I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. *What we can have is the following sequence of
events:

At time A we create bobble X. *Space will be allocated for X as
needed, including a struct bobble_s.

what's the difference between a bobble and a bobble_s?

At time B we schedule operation zeta to be performed on X at time
E. *Don't assume that X 'knows' that about the scheduled
operation.

At time C we delete bobble X. *All space is deallocated.

I'm not sure that'sa good idea. I think you need some sort
of collection of valid Bobbles (the last big OO project I
looked at called these Repositories). Operation zeta would be
given an identifier for X and not a reference to the actual X.

At time D we allocate bobble Y. *As it chances, Y has the same
address as X.

but a different identity.

At time E the program attempts to peform the scheduled operation
on X. *It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.

it asks the repository for X and provides the identifier.
The repository fails to find X and signals an error.

Simply hashing the address into an integer won't work because the
addresses are the same. *Likewise using an opaque pointer doesn't
work. *That's the point of the "unique id" - it is different for
different bobbles even though they have the same address.

apart from your solution looks slightly too complicated
don't you actaully *have* a solution?

You either ban the complete deletion of objects. Or objects
have well known places they live and unique identity. Some
OO books gone on quite a bit about identity.

Of course you can use sequence numbers as keys in a hash table or
some kind of search tree, but that is relatively computationally
expensive compared to the descriptor/locator paired structs.

I think if things can disappear behind your back then you're
going to have to live with the full horror of GUIDs.
--
Nick Keighley

The rabbit snarled and hefted his submachine gun angrily.
Ears back and teeth visible, he hissed at the cyborg.
Charles Stross "Singularity Sky"

[Eric Sosman]

Richard Harter wrote:

On Tue, 04 Nov 2008 22:34:53 -0500, Eric Sosman
<es*****@ieee-dot-org.invalidwrote:

>Richard Harter wrote:

>>On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@sun.comwrote:
Richard Harter wrote:
[...]
I am going to throw in one curve ball. Our program will contain
references to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.
As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. Your issues appear to deal with
representation hiding and validity checking, not with garbage
collection.
I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:

At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.

At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.

At time C we delete bobble X. All space is deallocated.

If zeta is still armed and dangerous, this seems to me to
be an error in the program, and not something a bobblefeature
should be expected to deal with. You're asking a destroyed
bobble to "remember" its former existence somehow, so it can
still respond in some way to an attempt to do something with
its non-existent self ... It doesn't seem to me that a robust
programming discipline should rely on spirit messages from the
afterlife.

You're misreading the situation. I'm not asking the destroyed
bobble to "remember" anything. How can it, when it no longer
exists? What I proposed was that zeta be able to detect the
non-existence of X when its time came. The technique I proposed
does require that the "locator" struct remain in existence; zeta
detects the non-existence of X by the mismatch of serial numbers.
However I don't see that as an onerous requirement.

Then "all space is deallocated" seems an overstatement.
If a bobble happens to consist of two, ten, or a hundred
separately-allocated memory areas, all of them are part of
the bobble even if only one happens to be a struct bobble_s.
Delete "all space," and there is nowhere left to record the
fact that "Kilroy was a bobble."

Retaining a bobble-fragment (a bobblet?) may be tenable.
The scheme as originally outlined, though, is not: If you
follow a pointer (or whatever) from a bobble locator to a
bobble that has been freed and try to inspect the freed bobble's
data, you are a gone goose. There's no telling what you might
find at the other end of a pointer to freed memory, if you in
fact find anything at all.

You could put the ex-bobble in a pool of "currently unused
bobble-sized blocks" and thus retain the ability to look at
its memory, and even to recycle the memory to hold a newer
bobble. But that's a far cry from "all space is deallocated."

Perhaps more importantly, I completely disagree with your view
that "If zeta is still armed and dangerous, this seems to me to
be an error in the program." Au contraire, in the situations I
am interested in it is an essential capability. As an example
think about a printer and the printer software. The printer
software is supposed to be able to deal with the fact that the
printer may be off line.

There's something about your analogy I find unconvincing:
Surely there's a difference between "The printer is off-line"
and "Printer? What printer? I don't see any printer here."
I suspect this means I haven't understood you; sorry.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Pascal J. Bourguignon]

cr*@tiac.net (Richard Harter) writes:

On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@sun.comwrote:

>>Richard Harter wrote:

>>Suppose we are writing a program in C and that we have a
particular kind of object (in the sense of OO programming) that I
will call bobbles. Being well disciplined programmers (Ha!) we
create a module to package our bobble related functions together.

If we were using an OO based language there would be machinery in
place, constructors, destructors, and such like, to handle the
details of our module, but in C we have to roll our own.

One of the things we need to do is to create functions that will
serve as constructors and destructors. There are two things that
we have to take care of, specifying the interface, and writing
the function internals. My concern is with specifying the
interface.

I am going to throw in one curve ball. Our program will contain
references to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.

As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. Your issues appear to deal with
representation hiding and validity checking, not with garbage
collection.

I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:

At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.

This is reasonable, we need to create objects.

At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.

This is reasonable, we need to be able to send messages to our
objects. But note that to be able to do so, we need to have a
reference to the recipient object.

At time C we delete bobble X. All space is deallocated.

This is the weak link.

At time D we allocate bobble Y. As it chances, Y has the same
address as X.

This is reasonable, we don't have infinite memory. But either X still
exists (and therefore Y shouldn't be allocated in the same memory
space) or X doesn't exist anymore, and therefore there's no "same
address" since X doesn't exist anymore.

"an object do exist" means "there are some references to the object".

At time E the program attempts to peform the scheduled operation
on X. It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.

There's no point. Either there is a reference to the object X, and
therefore X is still there, or there's no reference to X, and
therefore it doesn't matter if an object Y takes its place, and is
refered to with the same pointer.
It is clear that what's wrong in your hypotheses is "At time C we
delete bobble X. All space is deallocated." Just don't delete
objects. Once you've lost all references to an objects, your memory
management module is free to reuse the space, but not before. Yes, it
means:

Use a Garbage Collector!
If it's good enough for Apple, it should be good enough for you!
http://developer.apple.com/search.ph...lt_collection&
And by the way, are you sure there are not already enough Object
Systems implemented for/over C? Isn't Objective-C good enough for you?
Also have a look at: http://ldeniau.web.cern.ch/ldeniau/html/oopc.html

--
__Pascal Bourguignon__

[Richard Harter]

On Wed, 05 Nov 2008 00:22:54 GMT, cr*@tiac.net (Richard Harter)
wrote:

>On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@sun.comwrote:

>I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:

At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.

At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.

At time C we delete bobble X. All space is deallocated.

At time D we allocate bobble Y. As it chances, Y has the same
address as X.

At time E the program attempts to peform the scheduled operation
on X. It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.

Quite clearly the casual phrase "all space is deallocated" led to
all sorts of interesting interpretations. I suppose it won't do
to say "all of the space used in X is deallocated" - the same
sort of confusion will arise, because people will inevitably
assume that allocate means malloc and deallocate means free. So:

Assume that we are using memory management tools that exist as a
layer over malloc/free. Assume that "allocate" means "get valid
storage objects from the memory management tools for the entity
being created". Assume that "deallocate" means return the
entity's storage objects to the memory management tools.

How the memory management tools do this is, I hope, not relevant.
Okay?

Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Richard Harter]

On Wed, 05 Nov 2008 08:35:23 -0500, Eric Sosman
<es*****@ieee-dot-org.invalidwrote:

>Richard Harter wrote:

>On Tue, 04 Nov 2008 22:34:53 -0500, Eric Sosman
<es*****@ieee-dot-org.invalidwrote:

>>Richard Harter wrote:
On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<Er*********@sun.comwrote:
Richard Harter wrote:
>[...]
>I am going to throw in one curve ball. Our program will contain
>references to created bobbles; we won't know where these are so
>they can go stale when we delete bobbles. The code will need to
>be able to detect that a reference has gone stale and deal with
>it appropriately.
As far as I can see, the curve is orthogonal to the rest of
the discussion, so I'll ignore it. Your issues appear to deal with
representation hiding and validity checking, not with garbage
collection.
I may address the rest of your comments later (for which, thank
you very much) but this seems to be a serious point of confusion
so let me expand. What we can have is the following sequence of
events:

At time A we create bobble X. Space will be allocated for X as
needed, including a struct bobble_s.

At time B we schedule operation zeta to be performed on X at time
E. Don't assume that X 'knows' that about the scheduled
operation.

At time C we delete bobble X. All space is deallocated.

If zeta is still armed and dangerous, this seems to me to
be an error in the program, and not something a bobblefeature
should be expected to deal with. You're asking a destroyed
bobble to "remember" its former existence somehow, so it can
still respond in some way to an attempt to do something with
its non-existent self ... It doesn't seem to me that a robust
programming discipline should rely on spirit messages from the
afterlife.

You're misreading the situation. I'm not asking the destroyed
bobble to "remember" anything. How can it, when it no longer
exists? What I proposed was that zeta be able to detect the
non-existence of X when its time came. The technique I proposed
does require that the "locator" struct remain in existence; zeta
detects the non-existence of X by the mismatch of serial numbers.
However I don't see that as an onerous requirement.

Then "all space is deallocated" seems an overstatement.
If a bobble happens to consist of two, ten, or a hundred
separately-allocated memory areas, all of them are part of
the bobble even if only one happens to be a struct bobble_s.
Delete "all space," and there is nowhere left to record the
fact that "Kilroy was a bobble."

Well, yes, "all space is deallocated" is an over statement. See
the clarifying followup to the original. The intended meaning is
that all storage objects that are components of the bobble entity
no longer represent legitimate addresses.

>
Retaining a bobble-fragment (a bobblet?) may be tenable.
The scheme as originally outlined, though, is not: If you
follow a pointer (or whatever) from a bobble locator to a
bobble that has been freed and try to inspect the freed bobble's
data, you are a gone goose. There's no telling what you might
find at the other end of a pointer to freed memory, if you in
fact find anything at all.

To be honest, I don't think you understood the original scheme,
probably because we've clarifying side issues. The whole point
of the scheme is that you can detect that the object has been
deleted without looking at its (former) address. We do this by
comparing IDs.

I didn't spell this out in any detail, but it's sort of obvious.
When we delete a bobble we set the ID field of the locator to an
invalid ID, probably 0. If we reuse the locator (which I would
expect) for a new bobble, it gets a different unique ID. In all
cases an attempt to access a deleted bobble from a stale
reference will fail because the ID's don't match.

It occurs to me that you might be thinking of the locator struct
as a component of the bobble; it is not. It is a reference and
is a separate entity maintained by the bobble factory.

You could put the ex-bobble in a pool of "currently unused
bobble-sized blocks" and thus retain the ability to look at
its memory, and even to recycle the memory to hold a newer
bobble. But that's a far cry from "all space is deallocated."

>Perhaps more importantly, I completely disagree with your view
that "If zeta is still armed and dangerous, this seems to me to
be an error in the program." Au contraire, in the situations I
am interested in it is an essential capability. As an example
think about a printer and the printer software. The printer
software is supposed to be able to deal with the fact that the
printer may be off line.

There's something about your analogy I find unconvincing:
Surely there's a difference between "The printer is off-line"
and "Printer? What printer? I don't see any printer here."
I suspect this means I haven't understood you; sorry.

Yes, there's a difference. However to the bit of software that
is trying to print something it doesn't matter. What that piece
of software does is send a message to "the printer". Either the
message can be delivered or it can't. The ability to send the
message is independent of the actual existence of the target.

The issues here are ordinary issues in message passing
environments where the entities in the environment are transient.
Think of simulations.


Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Richard Harter]

On Wed, 5 Nov 2008 00:49:04 -0800 (PST), Nick Keighley
<ni******************@hotmail.comwrote:

>On 5 Nov, 00:22, [e-mail] (Richard Harter) wrote:

>On Tue, 04 Nov 2008 16:43:49 -0500, Eric Sosman
<[e-mail]:

>Richard Harter wrote

[snip]

>>>

At time A we create bobble X. =A0Space will be allocated for X as
needed, including a struct bobble_s.

what's the difference between a bobble and a bobble_s?

Metaphysics. :-)

Presumably we represent a bobble in the software by sundry
storage objects. This can be done in various ways. One way is
to use a master structure that has pointers to auxilliary storage
objects. Bobble_s is the master structure for X; the complete
collection of bits and pieces of X is the storage representation
of X. What X is depends upon your philosophic stance.

>

>At time B we schedule operation zeta to be performed on X at time
E. =A0Don't assume that X 'knows' that about the scheduled
operation.

At time C we delete bobble X. =A0All space is deallocated.

I'm not sure that'sa good idea. I think you need some sort
of collection of valid Bobbles (the last big OO project I
looked at called these Repositories). Operation zeta would be
given an identifier for X and not a reference to the actual X.

>At time D we allocate bobble Y. =A0As it chances, Y has the same
address as X.

but a different identity.

>At time E the program attempts to peform the scheduled operation
on X. =A0It has to be able to detect that X is no longer there even
though there is a bobble around with X's address.

it asks the repository for X and provides the identifier.
The repository fails to find X and signals an error.

Indeed. The issue at hand is designing the machinery for finding
X. In the method I ended up with the array of locator structs
serves as the repository.

>

>Simply hashing the address into an integer won't work because the
addresses are the same. =A0Likewise using an opaque pointer doesn't
work. =A0That's the point of the "unique id" - it is different for
different bobbles even though they have the same address.

apart from your solution looks slightly too complicated
don't you actaully *have* a solution?

You either ban the complete deletion of objects. Or objects
have well known places they live and unique identity. Some
OO books gone on quite a bit about identity.

>Of course you can use sequence numbers as keys in a hash table or
some kind of search tree, but that is relatively computationally
expensive compared to the descriptor/locator paired structs.

I think if things can disappear behind your back then you're
going to have to live with the full horror of GUIDs.

You might very well think that; I couldn't possibly comment.
Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Pierre Asselin]

In comp.lang.c Richard Harter <cr*@tiac.netwrote:

Er, the serial number approach was part of the original proposal.

Yes, but with a double indirection through intermediate structures
that I thought was unnecessary.

--
pa at panix dot com

[Richard Harter]

On Thu, 6 Nov 2008 01:35:41 +0000 (UTC), [e-mail]
(Pierre Asselin) wrote:

>In comp.lang.c Richard Harter <cr*@tiac.netwrote:

>Er, the serial number approach was part of the original proposal.

Yes, but with a double indirection through intermediate structures
that I thought was unnecessary.

Ah, I see. As it happens, that was the approach I took
originally. It works and I used it in the original
implementation; however I decided I didn't like it for several
reasons.

One is security; I didn't want the bobble address directly
visible in the user code. That's my choice; I consider opaque
pointers to be security by obscurity.

The second is that I wanted the potential capability of multiple
machines, i.e., the bobbles and the code accessing them might
reside on different machines without shared memory. In that case
one wants proxies; since proxies are on the table one might as
well use them uniformly.

Thirdly, I really don't want to be forced to maintain a free list
of bobbles for reasons other than storage management. It's one
thing to play that trick with locators aka proxies which are
small and single purpose; it's another to use it with the primary
entities which, we may suppose, are much larger and have other
purposes and multiple design considerations.

That said, your proposal works.

Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Lorenzo Villari]

Mr Harter, where I can find the sources of this project? I understand the
fact is not finished yet, but even a work in progress would be interesting
to see... or excuse me for this question if that was not meant to be
relesased for the public.

[Richard Harter]

On Thu, 6 Nov 2008 14:46:30 +0100, "Lorenzo Villari"
<vl****@alice.itwrote:

>Mr Harter, where I can find the sources of this project? I understand the
fact is not finished yet, but even a work in progress would be interesting
to see... or excuse me for this question if that was not meant to be
relesased for the public.

The code is all open source with a BSD style license. I'm
recoding this part at the moment. Give me a couple of days and
I'll post a URL.
Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Richard Harter]

On Thu, 6 Nov 2008 14:46:30 +0100, "Lorenzo Villari"
<vl****@alice.itwrote:

>Mr Harter, where I can find the sources of this project? I understand the
fact is not finished yet, but even a work in progress would be interesting
to see... or excuse me for this question if that was not meant to be
relesased for the public.

Look in directory http://home.tiac.net/~cri_a/san/source_code/

The code of interest is in

http://home.tiac.net/~cri_a/san/sour...ts/san_engine/

There isn't much documentation within the code, and it doesn't
yet test the deletion of the message target scenario.

Enjoy (or throw up, as the case may be).

Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Lorenzo Villari]

"Richard Harter" <cr*@tiac.netha scritto nel messaggio
news:49****************@news.sbtc.net...

Look in directory http://home.tiac.net/~cri_a/san/source_code/

The code of interest is in

http://home.tiac.net/~cri_a/san/sour...ts/san_engine/

Ok, thank you.