Hi,
Allen Bierbaum wrote:
> A couple of ideas that may be worth thinking about:
>
> - Using boost::shared_ptr's for the backreferences. I would very much
> like to see the memory handling in OpenSG become a little more robust.
> One way that I have used in my own code is to use boost::shared_ptr and
> boost::weak_ptr to make sure everything is collected correctly. This
> may be useful here to make sure nothing gets deleted early.
For a successful operation the lifetime of the objects is well known,
but since this is i/o I probably better think about exceptions as well...
> - Is there any way to look at the NFIOElement's as implementations of a
> strategy pattern that simply take a reference to a per-file global
> state. In more detail.
>
> What if the factory held a set of lightweight strategy objects. One
> instance per element type that needs custom handling. When a file needs
> to be written or read, the system creates a file-state object that track
> the global state needed for that single IO. Then as the process
> progresses the read/write algorithm core (possibly implemented inside
> the state tracking object) asks the factory object for the correct
> strategy to use for the encountered fc type. The factory will either
> return the generic strategy or a custom strategy. Then the algorithm
> still calls the read/postRead/preWrite/write methods but does so with an
> additional parameter, namely the file-state object.
>
> This would remove the threading issues because all data would be stored
> in the file-state object and it would make it so only one instance of
> the strategies for each custom fc type would ever need to be created.
> The strategies themselves would be thread-safe and re-entrant (ie.
> multiple read/writes could use the same strategy in parallel) because
> all the state would be held in the file-state object.
I decided (more or less consciously) against this, because it requires
the strategy objects to be stateless, i.e. all state needs to be in the
state object. This puts a restriction on extensibility, although I did
not check if the current code would be affected by this restriction.
> Note: I have not taken a look at the NFIO code based on this idea. I am
> just thinking of this from memory. So feel free to ignore the idea if
> it can't be realized with the current codebase.
I'll take a look if this is feasible, but I have the impression that for
example the (backwards compatibility) stuff done during postRead
requires a way of storing additional state depending on the FC type read.
Thanks for the input,
Carsten
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
