[saga-rg] context problem

[Andre Merzky]

Hi Pascal, 

no need for coffee (hehe, apart from the basic need we
probably all have), the example is good.

Indeed, it depends on where you maintain state.  The problem
is, however, that we cannot expect remote state management
as a default.  For example, a GridFTP based access to a
remote file, which is not far fetched as you will probably
agree, would need to maintain local state, as FTP does not
maintain server side state (for our purposes that is).

It is possible to keep API objects and state management
separate on client side (so within the saga implementation).
Indeed that ouwld solve the problem as well, as you then, in
some respect, avoid a really deep copy, but only copy
references to the real state management.  That in fact, as a
boundary case, corresponds to the usage of reference
counters and shallow copies again: the state management
would need to use the same refcounting and alloc/free
policies that one would use for object references in the
first place.

Cheers, Andre.


Quoting [Pascal Kleijer] (Jul 21 2006):
> 
> Hello Andre,
> 
> I will not come up with 3 counter arguments here. I will just show you 
> that your first argument is flawed (or think it is).
> 
> We assume that the following is the example code:
> 
>   task t_1 = file.seek <saga::task::task> (100, saga::file::SeekSet);
>   task t_2 = file.read <saga::task::task> (1, buf, &out);
>   t_1.run ();
>   t_1.wait ();
>   t_2.run ();
>   t_2.wait ();
> 
> In a traditional single machine implementation if we do a pure deep copy 
> of the file object in the task then do the run-wait calls, yes it might 
> be true that the read reads byte 1 and not byte 100. This depends on how 
> the file handler is implemented internally, if we stick to a pure deep 
> copy then it would mean the physical file is opened by two handles, thus 
> the "seek" of t1 does not affect t2.
> 
> In our case we are dealing with a _remote_ file due to the very nature 
> of SAGA. If we assume a WSRF implementation then the file object in our 
> sample code is noting more internally then a End Point Reference (ERP) 
> or similar depending on your implementation. Nothing is against having 
> two full duplicates (due to the deep copy) of the EPR but still point to 
> the same physical file with the same handle on the server site. When you 
> do the run-wait we can assume an atomic call, which means the byte that 
> is read is effectively # 100.
> 
> In a remote environment the real state of the object is not stored 
> locally (client). So when you do a "seek" it happens on the remote 
> object not locally. I would be a conception flaw if you did store the 
> file internal pointer as well as other properties locally. My assumption 
> is that you are mixing local and remote handling. Unless you want SAGA 
> to handle within one object both aspects, which again is a conception 
> flaw in my opinion.
> 
> I hope I was clear enough, otherwise I will need an extra run to the 
> coffee machine. :p
> 
> 
> 
> >>>>In the case of non-OO languages it might be preferable to use by copy 
> >>>>then by reference, this will however have an impact on the runtime but 
> >>>>will avoid you a lot of troubles.
> >>>I would assume that a non-OO implementations uses pointers
> >>>to structures as object representations, or handles or such.
> >>>Hence a copy would in fact represent a reference-copy, and
> >>>the same semantics can easily be achieved.
> >>Well no. The problem with non-OO languages and C++ is that you must 
> >>explicitly garbage collect your objects (call a destroy). So if you just 
> >>copy the pointer you cannot test if it has been destroyed unless you 
> >>handle the pointer to the pointer and can test for a NULL (agrl in 
> >>Fortran). So the idea is to make a full copy of the object state and use 
> >>a locale copy within the thread. This might cause a big overhead and be 
> >>rather tricky to implement, especially if object contains other objects. 
> >>The recursion in copy might be either impossible, longish or very complex.
> >
> >I disagree, and for two reasons even (that must be worth
> >something :-)
> >
> >For one, as I said in the thread earlier, I think that deep
> >copy raises huge semantic problems:
> >
> >  task t_1 = file.seek <saga::task::task> (100, saga::file::SeekSet);
> >  task t_2 = file.read <saga::task::task> (1, buf, &out);
> >
> >  t_1.run ();  
> >  t_1.wait ();
> >
> >  t_2.run ();  
> >  t_2.wait ();
> >
> >I, as a user, would assume that the read reads byte number
> >100.  But if we do a deep copy on task creation, the object
> >state (e.g. the file pointer) gets _copied_.  So the seek
> >operates on a different file pointer than the read, and the
> >read in fact returns the first byte in the file.
> >
> >That breaks a large number of use cases.
> >
> >
> >
> >Secondly, you are right, C++ and C must handle destruction
> >explicit - but that does not mean that you cannot copy
> >references.  It just means that your implementaion needs to
> >keep track of them!
> >
> >Now, that might be difficult, but (a) there are many libs
> >and tools helping with that and there also exist known
> >practices on how to do that, and (b) SAGA is about
> >ease-of-use, not ease-of-implementation.
> >
> >
> >Hehe, now you need three counterarguments :-)  Lets see what
> >you come up with :-D
> >
> >Cheers, Andre.
-- 
"So much time, so little to do..."  -- Garfield