corelinux-public — General discussions of CoreLinux++

[Corelinux-public] MemoryStorage iterator

[Frank V. C. <fr...@co...>]

I have enabled templatized iteration methods on the MemoryStorage class:

/**
forEach invokes the callers method to perform whatever operation they
want on
each Type entity of the storage area
@param Xexec call to templated type
*/

template < class Type, class Xexec >
   void  forEach( Xexec aExec )
   {
      REQUIRE( aExec != NULLPTR );

      GUARD;

      Type  *pType( (Type *)theBasePointer );
      Int   maxCount( theSize / sizeof( Type ) );

      for( Int x = 0; x < maxCount; ++x, ++pType )
      {
         (*aExec)(pType);
      }
   }


which allows things like:

template <class Type> void  zeroObject( Type *tp )
{
   REQUIRE( tp != NULLPTR );
   *tp = 0;
}

   MemoryStoragePtr aStorage( Memory::createStorage( ... ) );

   aStorage->forEach<Int>( zeroObject<Int> );


I did it this way to remove the need for a functor
hierarchy/specialization in the library space.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

Re: [Corelinux-public] 0.4.23 make install should not install tests

[Frank V. C. <fr...@co...>]

Here is some of what I'm thinking. And in reference to the package
building stuff it should be right in there with the rest of the CVS tree
for the particular area. This will simplify using the Compile Farm
machines to do the actual tar ball and packages (RPM/DEB). Of course, I
await other opinions.

CoreLinux++ libcorelinux
------------------------
CVS Path: 
corelinux

Packages: 
tar.gz, (like todays but take out examples)
Binary RPM/DEB (shared library, no make needed)
Developer RPM/DEB (make,static libs, headers, core-utils as well)

CoreLinux++ libcorelinux Examples
-------------------------------
CVS Path: 
core-examp

Packages: 
tar.gz. (need make, autoconf, etc.)

CoreLinux++ Utilities
---------------------
CVS Path: 
core-utils

Packages: tar.gz (just source, headers, make)

CoreLinux++ Frameworks
----------------------
CVS Path: 
core-frameXXXXXX (where X's = framework type)

Packages: 
tar.gz
Binary and develop RPM/DEB like libcorelinux for each framework

CoreLinux++ libcoreframe Examples
---------------------------------
CVS Path: 
core-frameexamp

Packages: 
tar.gz. (need make, autoconf, etc.)

CoreLinux++ Applications
------------------------
CVS Path: 
core-applsXXXX (where X's = application)

Packages: 
tar.gz
Binary and developers RPM/DEB like core and frameworks



"Frank V. Castellucci" wrote:
> 
> Christophe Prud'homme wrote:
> >
> > By the way it would be nice to settle this issue once for good since
> > I am in the packages(rpm/deb) building process.
> > So quick feedback and ideas on this is much appreciated.
> >
> > A minor change from my previous mail;
> > corelinux-examples can be:
> > o installed (the sources) under the corelinux dirs(doc/share), so that
> >   people can browse the code and eventually copy the hierachy
> > o provided as an archive still under corelinux dirs and people can untar/build
> >   examples wherever they want.
> >
> > what do you think?
> >
> > chris
> 
> I will write out the near and long term scenarios in a follow up
> message. There is more to consider:
> 
> 1. Examples
> 2. Packages (rpm/deb/etc)
> 3. Utilities (corelinux developers)
> 4. Frameworks (stress the plural)
> 5. Applications (real ones, not the examples)
> 6. SourceForge modules vs. new projects
> 
> --
> Frank
> 
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

Re: [Corelinux-public] 0.4.23 make install should not install tests

[Frank V. C. <fr...@co...>]

Christophe Prud'homme wrote:
> 
> By the way it would be nice to settle this issue once for good since
> I am in the packages(rpm/deb) building process.
> So quick feedback and ideas on this is much appreciated.
> 
> A minor change from my previous mail;
> corelinux-examples can be:
> o installed (the sources) under the corelinux dirs(doc/share), so that
>   people can browse the code and eventually copy the hierachy
> o provided as an archive still under corelinux dirs and people can untar/build
>   examples wherever they want.
> 
> what do you think?
> 
> chris

I will write out the near and long term scenarios in a follow up
message. There is more to consider:

1. Examples
2. Packages (rpm/deb/etc)
3. Utilities (corelinux developers)
4. Frameworks (stress the plural)
5. Applications (real ones, not the examples)
6. SourceForge modules vs. new projects 

-- 
Frank

Re: [Corelinux-public] 0.4.23 make install should not install tests

[Christophe Prud'h. <pru...@MI...>]

By the way it would be nice to settle this issue once for good since 
I am in the packages(rpm/deb) building process.
So quick feedback and ideas on this is much appreciated.


A minor change from my previous mail;
corelinux-examples can be:
o installed (the sources) under the corelinux dirs(doc/share), so that 
  people can browse the code and eventually copy the hierachy
o provided as an archive still under corelinux dirs and people can untar/build
  examples wherever they want. 

what do you think?

chris

-- 
     Christophe Prud'homme                    |
     MIT, 77, Mass Ave, Rm 3-243              |     To err is human,
     Cambridge MA 02139                       |     to repent, divine,
     Tel (Office) : (00 1) (617) 253 0229     |     to persist, devilish.
     Fax (Office) : (00 1) (617) 258 8559     |     -- Benjamin Franklin
     http://augustine.mit.edu/~prudhomm       |

Re: [Corelinux-public] 0.4.23 make install should not install tests

[Christophe Prud'h. <pru...@MI...>]

    >>
    >> Subject says it all.  Please don't install the test examples with 'make install'.

    Frank> A. Should the 'make install' ignore even compiling the examps?
    Frank> B. Should it be an optional argument to ./configure ?
    Frank> C. Should we break out the examples from the library distribution
    Frank> altogether?

my opinion on this would be to copy the examples source hierarchy under doc or shared dir 
and people can rebuild the example. So the C solution you propose is the best from my point of view

we would have 

corelinux-base / corelinux
corelinux-examples
corelinux-doc


chris

-- 
 Christophe Prud'homme                | Pierre: Je suis désolé Thérèse, je ne
 MIT, 77, Mass Ave, Rm 3-243          |         sais pas ce qui m'a pris...
 Cambridge MA 02139                   |         c'est une catastrophe.
 Tel (Office) : (00 1) (617) 253 0229 | Thérèse: Ce n'est rien Pierre,
 Fax (Office) : (00 1) (617) 258 8559 |          je n'ai rien senti....
 http://augustine.mit.edu/~prudhomm   | -- Le Pere Noel est une ordure

Re: [Corelinux-public] 0.4.23 make install should not install tests

[Frank V. C. <fr...@co...>]

"Neal D. Becker" wrote:
> 
> Subject says it all.  Please don't install the test examples with 'make
> install'.
> 
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

This brings up a good point. Some feedback please:

A. Should the 'make install' ignore even compiling the examps?
B. Should it be an optional argument to ./configure ?
C. Should we break out the examples from the library distribution
altogether?


Thanks for your time.

-- 
Frank V. Castellucci

[Corelinux-public] 0.4.23 make install should not install tests

[Neal D. B. <nb...@fr...>]

Subject says it all.  Please don't install the test examples with 'make
install'.

[Corelinux-public] subset and combine checked in

[Frank V. C. <fr...@co...>]

Ok,
Checked in the reclaim implementation. Actually, it is no longer reclaim
but:

subsetGroup
combineGroup

which do what I explained earlier.

I also added better boundry conditions to the registration process.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Corelinux-public] Quick responses

[Frank V. C. <fr...@co...>]

It didn't take long, people have e-mailed me about the "reclaim"-ation
of CSA blocks when a group is no longer being shared (-1).

I originally was thinking of using this for the implementation:

void  SemaphoreCommon::reclaimGroup( CSAGrpHeaderPtr aGroup, Int aIndex
)
{
   //
   // Walk to the end, we need to dupe the pointer to
   // protect the reclaim test.
   //

   if( aIndex < theBase->currentGrps )
   {
      CSAGrpHeaderPtr   nextGroup( aGroup );
      nextGroup += ( aGroup->groupSemCount + ON );
      this->reclaimGroup( nextGroup,( aIndex + ON ) );
   }
   else
   {
      ;  // do nothing
   }

   //
   // If we are the last one and we can be reclaimed, do so.
   //

   if( aIndex == theBase->currentGrps && aGroup->groupInfo == -ON )
   {
      theBase->currentGrps -= ON;
      theBase->currentUsed -= aGroup->groupSemCount;
      aGroup->groupInfo = OFF;
   }
   else
   {
      ;  // do nothing
   }
}

but it became obvious that in the degenerate case the stack on the
recursion would approach 1.5 k! I don't like this, especially for
secondary threads.

So what I am now thinking that:

* If the group being deregistered determines if he is the tail, he just
takes himself off the end. 

* During registration, if there is no more space, and the
findAvailableGroup can not get an exact match,
  a subset method will adjust a group that has more than needed to
service the request, and put a defunct 
  group header for integrity. Basically splitting one group into two.

* If the required resources is greater than a single group, adjacent
groups that are defunct will be joined
  into one group, with required adjustments being made, and then allow
the subset method to do its thing.

This adds cycle overhead, but I would much rather be accused of eating
cpu cycles than crashing applications.

Thoughts?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

Re: [Corelinux-public] Its up

[John A. <joh...@oc...>]

"Frank V. Castellucci" wrote:

> John Allen wrote:
> >
> > "Frank V. Castellucci" wrote:
> >
>

snipped

> >
> > Unfortunately Linux threads don't work quite right. Normally when
> > a parent process dies, it takes all threads with it, but not on Linux.
> >
> > The child threads continue merrily on their way. This makes it a
> > pain to implement SIGHUP, SIGTERM etc...
>
> Joy. So, because I can't "handle" those signals, they will chug along? I
> was thinking that with the main thread handling the critical signals,
> the Thread management could kill the threads itself.
>

Yes basically you have to have the main thread handle all signals,
and ensure that catastrpohic ones, such as SIGHUP, SIGSEGV, SIGINT
get propogated to the chidl threads.

Probably easier for Corelinux, than for my project as I have to do it in
a multi-platform fashion.

>
> --
> Frank
>
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

--
John Allen                         email: joh...@oc...
OpenSource Developer               www: http://www.vptk.org
                                   phone: intl+353-862315986

Re: [Corelinux-public] Its up

[Frank V. C. <fr...@co...>]

John Allen wrote:
> 
> "Frank V. Castellucci" wrote:
> 
> > I have checked it all in. I will be releasing 0.4.23 in the am
> > (EST).
> >
> > In a previous note I mentioned the need for a better way of creating
> >
> > unique keys for the System V IPC when instantiating private
> > SemaphoreGroups and Memory object. The implementation currently uses
> > the
> > file approach (with ftok) and it works.
> >
> > For private objects I tried creating the file temporarily to get the
> >
> > ftok and then unlinking the file, but lo and behold the ftok
> > function
> > uses inode information will is not always unique (especially after
> > just
> > creating a file and unlinking it). Collision mania, so I had to
> > leave
> > the file out there until the object destruction. Oh well.
> >
> 
> Try keeping the file open, and unlinking it, that should not release
> the
> i-node until the file is closed.

That is what I basically have done (although I don't keep the file open
I leave it out there until the object which created it is being destroy,
AND, the reference count is 0), but I was looking for a way to create it
use the ftok and get rid of it. The problem occurs because right on the
heels of that activity, another object attempts to do the same thing,
but the ftok value is the same as the last, thereby causing either
semget or shmget to fail because the key is in use and I express
IPC_EXCL.

This is primarilty a problem for those objects that are considered
private, I need a strongly foolproof unique key generate that doesn't
involve the ftok i-node debacle.

> 
> >
> > What I have done is move the creation and removal of object key
> > files to
> > the new Environment class interface.
> >
> > SmartPointer discussion has made me think, it would be wise to have
> > the
> > base most SmartPointer with reference counting in libcorelinux, and
> > so
> > it shall be. Anyone want to do it?
> >
> > For that matter, does anybody want to do any of the class library
> > work
> > at all?
> >
> > I have also checked in updates to the Developers Guide. This will be
> >
> > scarey for a while until I learn TeX tags.
> >
> > I need help with Signals, Threads, and their can/can't/should/should
> >
> > nots from a Linux perspective.
> >
> 
> Ah, Linux threads.
> 
> Unfortunately Linux threads don't work quite right. Normally when
> a parent process dies, it takes all threads with it, but not on Linux.
> 
> The child threads continue merrily on their way. This makes it a
> pain to implement SIGHUP, SIGTERM etc...

Joy. So, because I can't "handle" those signals, they will chug along? I
was thinking that with the main thread handling the critical signals,
the Thread management could kill the threads itself.

-- 
Frank

Re: [Corelinux-public] Its up

[John A. <joh...@oc...>]

"Frank V. Castellucci" wrote:

> I have checked it all in. I will be releasing 0.4.23 in the am (EST).
>
> In a previous note I mentioned the need for a better way of creating
> unique keys for the System V IPC when instantiating private
> SemaphoreGroups and Memory object. The implementation currently uses the
> file approach (with ftok) and it works.
>
> For private objects I tried creating the file temporarily to get the
> ftok and then unlinking the file, but lo and behold the ftok function
> uses inode information will is not always unique (especially after just
> creating a file and unlinking it). Collision mania, so I had to leave
> the file out there until the object destruction. Oh well.
>

Try keeping the file open, and unlinking it, that should not release the
i-node until the file is closed.

>
> What I have done is move the creation and removal of object key files to
> the new Environment class interface.
>
> SmartPointer discussion has made me think, it would be wise to have the
> base most SmartPointer with reference counting in libcorelinux, and so
> it shall be. Anyone want to do it?
>
> For that matter, does anybody want to do any of the class library work
> at all?
>
> I have also checked in updates to the Developers Guide. This will be
> scarey for a while until I learn TeX tags.
>
> I need help with Signals, Threads, and their can/can't/should/should
> nots from a Linux perspective.
>

Ah, Linux threads.

Unfortunately Linux threads don't work quite right. Normally when
a parent process dies, it takes all threads with it, but not on Linux.

The child threads continue merrily on their way. This makes it a
pain to implement SIGHUP, SIGTERM etc...

>
> I will be adding iteration to MemoryStorage objects soon. Some clean up
> and factoring is bound to happen as well. Continued Environment
> interface and function.
>
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> http://PythPat.sourceforge.net
> Pythons Pattern Package
>
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

--
John Allen                         email: joh...@oc...
OpenSource Developer               www: http://www.vptk.org
                                   phone: intl+353-862315986

[Corelinux-public] Its up

[Frank V. C. <fr...@co...>]

I have checked it all in. I will be releasing 0.4.23 in the am (EST).

In a previous note I mentioned the need for a better way of creating
unique keys for the System V IPC when instantiating private
SemaphoreGroups and Memory object. The implementation currently uses the
file approach (with ftok) and it works.

For private objects I tried creating the file temporarily to get the
ftok and then unlinking the file, but lo and behold the ftok function
uses inode information will is not always unique (especially after just
creating a file and unlinking it). Collision mania, so I had to leave
the file out there until the object destruction. Oh well.

What I have done is move the creation and removal of object key files to
the new Environment class interface.

SmartPointer discussion has made me think, it would be wise to have the
base most SmartPointer with reference counting in libcorelinux, and so
it shall be. Anyone want to do it?

For that matter, does anybody want to do any of the class library work
at all?

I have also checked in updates to the Developers Guide. This will be
scarey for a while until I learn TeX tags.

I need help with Signals, Threads, and their can/can't/should/should
nots from a Linux perspective. 

I will be adding iteration to MemoryStorage objects soon. Some clean up
and factoring is bound to happen as well. Continued Environment
interface and function. 

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Corelinux-public] Shared MutexSemaphore checked in

[Frank V. C. <fr...@co...>]

Ok, it's checked in and it works.

Couple of notes:

* I am using the /tmp/xxx.yyy for creating unique keys for semaphores
(ftok requires a valid file). This is sloppy in that it incurs IO for
creating and removing SemaphoreGroups. If someone has a bullet proof
unique key create idea let me know and I will use it instead, there is
no need for using files.

* I changed interface and refactored AbstractSemaphore/Semaphore a bit.

* Removed some of the pre-includes from Common.hpp

* The SemaphoreCommon will NOT page and group lock for semaphore
changes, just group lock which will prevent a destructive CSA activity
(it cascades the locks for this type stuff).


So now I do the same for GatewaySemaphore this weekend for Jun 5 2000
release (0.4.23).

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Corelinux-public] Refinement checked in

[Frank V. C. <fr...@co...>]

The CSA is now locking itself and groups that are being serviced.

There is also a sample (ex21) which requires that you use two (2)
shells.
Start the first example as a server (with no arguments e.g. .libs/ex21
[enter])
Start the second example as the client (with 1 arbitrary argument
.libs/ex21 foo [enter])

All this does is manage the registering, instrumentation, and
deregistering of shared (Mutex only) semaphore groups.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Corelinux-public] Direction for SemaphoreGroups

[Frank V. C. <fr...@co...>]

Ok, this is the route I am going:

When shared (named) semaphore groups are created, they are registered in
the Semaphore Common Storage Area, this includes use of a group
descriptor and a descriptor for each semaphore.

The CSA contains it's own MutexSemaphoreGroup for controlling access to
the CSA (although there is a temporary monitor in place it is
ineffective across multiple processes for obvious reasons.

Each shared group, when registered, gets a pointer back to it's group
descriptor. When any operation is to be performed on the SemaphoreGroup
(create/open/delete a semaphore) a pass is made back to the CSA Object
with itself to lock the page as well as a semaphore that is used to lock
the group descriptor and it's members. The CSA will assume the LAST
semaphore in the group is the control semaphore, because of this all
shared named sempahore groups in the library increment the user count of
semaphore requests by 1. This will insure that the group used between
two processes are utilizing the SAME semphore for state control through
the CSA. I am going with the pessimistic approach for the time being
until all the use cases are worked out. But the semaphore groups are not
aware of the page and row lock so changing it in the future will not
effect the operation.

Now, the hard part is the actual semphore work. As with group, a change
to a semaphore will require the group lock which will ignite the page
lock, which is fine. All state changes within the semaphore that are
part of the semaphore CSA descriptor will need to be kept up to date.

So the interface changes will be:

SemaphoreCommon becomes a friend of SemaphoreGroup 
SemaphoreGroup has a new private data member which is the CSA Group
Header (this is only initialized for non-Private groups.
All SemaphoreGroup (SG) types (Mutex,Gateway) will increment the
semaphore count upon creation of shared non-private.
All SG types will test for private or shared state and handle the
requests (locally), or enhance the processing with a pass back to the
SemaphoreCommon for requests.
All Semaphores will be instantiated with their respective semaphore
group POINTER (instead of identifier). The indirection of state changes
from the semaphore will happen through the group.

That is what I am working on.

If any one needs clarification WHY this is being done, pop a note. 
-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Corelinux-public] Tweaks and twirls

[Frank V. C. <fr...@co...>]

Ok, some more work checked in.

I have the private semaphore group solved with multiple processes, in
that it creates a (hopefully) unique file in /tmp that is used to ftok,
which means no two run-times will share the key. It works with prelim
testing.

fork() is a problem. Apparently Linux (2.2.12-20) does not fully create
address space on demand as far as static initializers in the
libcorelinux, specifically the CoreLinuxGuardPool. It seems, and I
haven't and won't get into the nibbles on this, that one instances
static initializers are enough to satisfy the forking code.

At anyrate some changes to the library (CVS) include:

* Static member addition of a MutexSemaphoreGroup for use by the
Semaphore CSA (Common Storage Area). We can't have multiple instance
management routines stepping on each others feet in shared mem. At the
moment, I have just gotten over the creation and cleanup of said sem
group. I now need to change the groups themselves to work with the CSA.

* Addition of SemaphoreGroup private instantiation key protection (the
/tmp file thing named above).

* Addition of char buffer for each Semaphore group to save the name for
cleanup

* Changes in SemaphoreGroup destructors and constructors.

Off to the day job so I will be putting this together evenings with a
end of week target.

Thoughts, suggestions, flames are welcome and encouraged (although I
won't resort to calling anyones mother a foul name).


-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Corelinux-public] Shared Semaphore Groups (multi-process)

[Frank V. C. <fr...@co...>]

Well I've been busy...

The latest point (CVS) contains some changes which enable multiple
processes to share a semaphore group. This is just the initial feed
which maintains a shared memory segment which tracks group access. 

The real work will now be in the communication between the address space
groups and their semaphores.

It has been tested with different processes using the same named group
(one originator and one user). Using the same app with fork() fails
because I have to cleanup the GuardPool which (only realizing now that
the IPC_PRIVATE can only be used once per address space) will have a
unique instance key.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

Re: [Corelinux-public] SmartPointer Draft 0.2 (work in progress)

[Frank V. C. <fr...@co...>]

John Allen wrote:

> "Frank V. Castellucci" wrote:
>
> > Further thoughts captured, modifications made, feedback and contribution
> > please:
> >
> > CoreLinux++ SmartPointer Draft 0.2
> > ==================================
> >
> > A SmartPointer is a lightweight proxy that substitutes itself for a
> > object instance until which point access requires said instance to be
> > instantiated.
> >
>
> I would also like an similar SmartPointer (SharedPointer) that just
> provides reference counting, and not instantiation.
>

See comments further down the line

>
> >
> > A base SmartPointer should:
> > ---------------------------
> >
> > * Be thread safe. (Synchronized object)
>
> Yes
>
> >
> > * Survive instance type queries (casting, testing, etc.). Templated
> > class
>
> Please explain further

SmartPointers need to survive the same type of RTTI queries and casts as do
the first class objects they represent. In my practive I have done this two
ways:

1. The SmartPointer hierarchy maps to the class hierarchy it services

2. A Meta-class is created for each object and the SmartPointer casts and
queries are delegated to the class DAG to figure out. Of course, this was
prior to the RTTI standards being defined (see NIH Class class). But, one of
the aspects of libcorelinux is that there is no dependency on RTTI if the
user/developer elects to disable it. That does not neccessary apply to the
moduler frameworks but I anticipate the same request/complaint would arise if
we were to go RTTI.

> >
> > * Be independent of faulting in the underlying instance. Templated
> > methods with default implementations.
>
> Again, please explain further

When working with persistent implementations and cache/memory management the
SmartPointer can't assume a "new" instantiation for objects when they are
needed.

> >
> > * Default to heap based instantiation
>
> Yes
>
> >
> > * Contains reference instrumentation
>
> Yes
>
> >
> >
> > An immediate derivation for the framework extensions:
> > -----------------------------------------------------
> > * Have identity. I believe this to be neccessary for persistence and
> > faulting capability.
> >
> > SnartPointer Pros
> > -----------------
> > * Less memory required.
>
> Only if a large proportion of objects are not instantiated.

I spoke ahead of myself here. The last system I implemented, using
SmartPointers with persistent objects, scaled itself through use of reference
counts and garbage collection. Not only where non-dirty unreferenced objects
released back into the pool, but so were the SmartPointers under the same
premise that objects live and die quickly as a rule. In addition, we even had
a built-in swap for dirty objects that had not been referenced in awhile
(although for this case the SmartPointer was kept around as it was measured
less expensive to just do so rather than re-fault in the SmartPointer for the
swapped object).

> >
> > * Reduced heap fragmentation (with factory and/or heap managed
> > instantiation).
> > * More scalable
> >
> > SmartPointer Cons
> > -----------------
> > * Require a less natural way of object referencing:
> >
>
> This should not be the case, should be callable like
> SmartPointerPtr->instanceOperation(...)

This implies that SmartPointers fully delegate interface. This is not
desirable on a number of fronts, unless I mis-read your point.

> >
> > (*SmartPointerPtr)->instanceOperation(...)
> >
> > * Require pervasive and strict management of references for example:
> >
>
> One possibility is that the SmartPointer<> does not provide direct access,
> or casting to the pointer type. This can however be somewhat awkward
> in practice.

Agreed, my "con" point is just observation. Those of us that have used them
tend to get over the usage curve when the benefits are realized.

> >
> >         Assuming that the underlying iterator increments the reference
> > count
> >
> >         for( iterator<SmartPointerPtr> aItr=...;
> >            aItr->isValid();
> >            aItr->setNext() )
> >         {
> >            SmartPointerPtr aObject( aItr->getElement() );
> >            (*aObject)->doSomething(...);
> >         }
> >
> > would leak reference, unless it was something like:.
> >
> >         for( iterator<SmartPointerPtr> aItr=...;
> >            aItr->isValid();
> >            aItr->setNext() )
> >         {
> >            SmartPointerPtr aObject( aItr->getElement() );
> >            (*aObject)->doSomething(...);
> >            aItr->returnElement( aObject );
> >         }
> >
> > Issues
> > ------
> > * There is a knee of the curve extension by using SmartPointers instead
> > of resident instances. But, it just moves the knee further out.
> >
> > * Once the instance is instantiated, the SmartPointer goes away? My
> > experience has been that the solution space assumes constant use of the
> > smart pointer as proxy to instance.
> >
>
> The SmartPointer should never go away, as it is the focal point for the
> automatic management of reference counting,  be it simple reference
> counting or object maps.

Frank

Re: [Corelinux-public] SmartPointer Draft 0.2 (work in progress)

[John A. <joh...@oc...>]

"Frank V. Castellucci" wrote:

> Further thoughts captured, modifications made, feedback and contribution
> please:
>
> CoreLinux++ SmartPointer Draft 0.2
> ==================================
>
> A SmartPointer is a lightweight proxy that substitutes itself for a
> object instance until which point access requires said instance to be
> instantiated.
>

I would also like an similar SmartPointer (SharedPointer) that just
provides reference counting, and not instantiation.

>
> A base SmartPointer should:
> ---------------------------
>
> * Be thread safe. (Synchronized object)

Yes

>
> * Survive instance type queries (casting, testing, etc.). Templated
> class

Please explain further

>
> * Be independent of faulting in the underlying instance. Templated
> methods with default implementations.

Again, please explain further

>
> * Default to heap based instantiation

Yes

>
> * Contains reference instrumentation

Yes

>
>
> An immediate derivation for the framework extensions:
> -----------------------------------------------------
> * Have identity. I believe this to be neccessary for persistence and
> faulting capability.
>
> SnartPointer Pros
> -----------------
> * Less memory required.

Only if a large proportion of objects are not instantiated.

>
> * Reduced heap fragmentation (with factory and/or heap managed
> instantiation).
> * More scalable
>
> SmartPointer Cons
> -----------------
> * Require a less natural way of object referencing:
>

This should not be the case, should be callable like
SmartPointerPtr->instanceOperation(...)


>
> (*SmartPointerPtr)->instanceOperation(...)
>
> * Require pervasive and strict management of references for example:
>

One possibility is that the SmartPointer<> does not provide direct access,
or casting to the pointer type. This can however be somewhat awkward
in practice.

>
>         Assuming that the underlying iterator increments the reference
> count
>
>         for( iterator<SmartPointerPtr> aItr=...;
>            aItr->isValid();
>            aItr->setNext() )
>         {
>            SmartPointerPtr aObject( aItr->getElement() );
>            (*aObject)->doSomething(...);
>         }
>
> would leak reference, unless it was something like:.
>
>         for( iterator<SmartPointerPtr> aItr=...;
>            aItr->isValid();
>            aItr->setNext() )
>         {
>            SmartPointerPtr aObject( aItr->getElement() );
>            (*aObject)->doSomething(...);
>            aItr->returnElement( aObject );
>         }
>
> Issues
> ------
> * There is a knee of the curve extension by using SmartPointers instead
> of resident instances. But, it just moves the knee further out.
>
> * Once the instance is instantiated, the SmartPointer goes away? My
> experience has been that the solution space assumes constant use of the
> smart pointer as proxy to instance.
>

The SmartPointer should never go away, as it is the focal point for the
automatic management of reference counting,  be it simple reference
counting or object maps.

> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> http://PythPat.sourceforge.net
> Pythons Pattern Package
>
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

--
John Allen                         email: joh...@oc...
OpenSource Development             www: http://www.vptk.org
Virtual Platform Toolkit           phone: intl+353-862315986

Re: [Corelinux-public] State checked in

[Christophe Prud'h. <pru...@MI...>]

    Thomas> Frank: Have you considered using the DocBook format like the Linux Documentation Project
    Thomas> has converted to?
Hi

I am the one who managed to convince Frank about the doc format.
Here is my opinion, I have tested and used many kind of documentation formats
and no one come near TeX/LaTeX in terms of power, flexibility, avaibility and packages. 

christophe
-- 
     Christophe Prud'homme                    |
     MIT, 77, Mass Ave, Rm 3-243              |     To err is human,
     Cambridge MA 02139                       |     to repent, divine,
     Tel (Office) : (00 1) (617) 253 0229     |     to persist, devilish.
     Fax (Office) : (00 1) (617) 258 8559     |     -- Benjamin Franklin
     http://augustine.mit.edu/~prudhomm       |

Re: [Corelinux-public] State checked in

[Thomas D. J. <ac...@pr...>]

Frank:

Have you considered using the DocBook format like the
Linux Documentation Project has converted to?

-- Tom.

"Frank V. Castellucci" wrote:

> The last pattern requirement (State) has been implemented and checked
> in.
>
> It will be in the 0.4.22 release which should be a few days. I am having
> trouble figuring out how LaTeX can find the latex2html styles.
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> http://PythPat.sourceforge.net
> Pythons Pattern Package
>
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

[Corelinux-public] SmartPointer Draft 0.2 (work in progress)

[Frank V. C. <fr...@co...>]

Further thoughts captured, modifications made, feedback and contribution
please:

CoreLinux++ SmartPointer Draft 0.2
==================================

A SmartPointer is a lightweight proxy that substitutes itself for a
object instance until which point access requires said instance to be
instantiated.

A base SmartPointer should:
---------------------------

* Be thread safe. (Synchronized object)
* Survive instance type queries (casting, testing, etc.). Templated
class
* Be independent of faulting in the underlying instance. Templated
methods with default implementations.
* Default to heap based instantiation
* Contains reference instrumentation

An immediate derivation for the framework extensions:
-----------------------------------------------------
* Have identity. I believe this to be neccessary for persistence and
faulting capability.

SnartPointer Pros
-----------------
* Less memory required.
* Reduced heap fragmentation (with factory and/or heap managed
instantiation). 
* More scalable

SmartPointer Cons
-----------------
* Require a less natural way of object referencing:
  
  (*SmartPointerPtr)->instanceOperation(...)

* Require pervasive and strict management of references for example:

        Assuming that the underlying iterator increments the reference
count

        for( iterator<SmartPointerPtr> aItr=...; 
           aItr->isValid(); 
           aItr->setNext() )
        {
           SmartPointerPtr aObject( aItr->getElement() );
           (*aObject)->doSomething(...);
        }

would leak reference, unless it was something like:.

        for( iterator<SmartPointerPtr> aItr=...; 
           aItr->isValid(); 
           aItr->setNext() )
        {
           SmartPointerPtr aObject( aItr->getElement() );
           (*aObject)->doSomething(...);
           aItr->returnElement( aObject );
        }

Issues
------
* There is a knee of the curve extension by using SmartPointers instead
of resident instances. But, it just moves the knee further out.

* Once the instance is instantiated, the SmartPointer goes away? My
experience has been that the solution space assumes constant use of the
smart pointer as proxy to instance.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Corelinux-public] CoreLinux++ 0.4.22 Released

[Frank V. C. <fr...@co...>]

Up and available.

I broke the documentation distributions out to

TeX
DVI
PDF

each contain the class reference HTML produced by Doc++

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

[Corelinux-public] State UML posted

[Frank V. C. <fr...@co...>]

Ok, the analysis and design web stuff is up after struggling with .tex
and TeX and latex and latex2html (Christophe assured me this is much
better, reminds me of when my parents would whack me for my own good).

I want to change the doc distribution before releasing and get some
"press releases" for various news-sources out about the pattern
completion. Be a few days yet.

There has been no other feedback on the SmartPointer from when I posted
the Draft 0.1, is that it?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package