rsync on OpenVMS

[jw schultz]

On Wed, Oct 22, 2003 at 11:59:48PM -0400, John E. Malmberg wrote:
> jw schultz wrote:
> >On Tue, Oct 21, 2003 at 11:28:11PM -0400, John E. Malmberg wrote:
> >
> >>
> >>There are approximately 235 global and static variables in rsync, and
> >>of those 105 are obviously never modified after the fork() takes place. 
> >>That may be the case for several of the others, like the 10 in batch.c
> >>
> >>As the use of the remaining ones are identified, that issue is easily 
> >>fixed.  What I need to do is map the routines called by the receive 
> >>process/thread to see what static/global variables that they modify.
> >>
> >
> >If you put the ones that get modified post-fork into a
> >thread-local structure there is a reasonable chance of that
> >getting into mainline.
> 
> Now what would be more acceptable:
> 
> Adding a context parameter to all the routines that reference the 
> global/static variables that are currently shared?
> 
> or
> 
> Having each routine that uses those type of variables to go through the 
> work of determining which thread that they are in?
> 
> 
> It seems to me that adding the context parameter would make it easier to 
> maintain, and have a lower overhead.  It also saves having thread lookup 
> calls added to the routines.
> 
> In some other cases, it looks like the sharing should not hurt, but 
> their should be some synchronization.

Long term thread support would be to use a pointer in thread
local storage or to pass it to any functions that use it.

For now just define the structure and treat it as global in
mainline.

> Since there are only two processes or threads that need to be tracked, 
> while the parameter could be a pointer to global structure, it can be 
> disruptive to put all the local thread specific static values in that 
> structure.  Mainly because a lot of them have the same symbol names, 
> just different scope.
> 
> So there could be a global variable that is  void * recv_context, and a 
> void * send_context for the sender for completeness.

That sounds like it might be OK to me but will require much
more thought and discussion.

> A routine that needs separate local static variables would check the 
> context parameter passed to it against one of those pointers, and then 
> use the appropriate set of local variables.

That sort of indirection just complicates things.  If you
are going to pass a context parameter just pass the pointer
to the structure itself.

> With this, the static variables would become an array, and the context 
> parameter would determine if index 0 or 1 was used.

There are up to three processes.

Local has sender, generator and receiver.
Daemon has the daemon and either the sender, or the generator
and receiver.
Client has either sender or generator and receiver.

Getting it threadable will have to be done by inches.

The structure is a single step that should help to reduce
the size of your patches while enhancing the documentation
of some of the globals.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt