Re: Threads

[Jason Gunthorpe <jgg@gpu.srv.ualberta.ca>]

On 20 Oct 1997, Manoj Srivastava wrote:

> Hi,
> >>"Jason" == Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> writes:
> 
> Jason> Well, there are portions that are not event driven and it seems
> Jason> to be simpler to use threads for those bits. Ie consider
> Jason> generating the cache file, that is quite a lengthy operation
> Jason> and deserves a dialog, but I can't do that without either
> Jason> spawning another program and setting up a pipe or using a
> Jason> thread.
> 
> 	What does the dialog do? (I'm confused here). Can it be done
>  with timers? 

It says 'Reading Package files, please wait. xx% complete'. Or something
to that effect. The trouble is the complexity of the cache generator makes
it easilly implementable only as a single function call (as the client
would percieve it) so it would block the entire GUI. And the gui update
scheme requires that it be free to run the select loop. 

It is not easy (or likely desirable) to cook something up to support cases
like this without a concurrency through processes or threads.
 
> Jason> With GUI's it is usefull to have the main rendering section in
> Jason> it's own thread so computation doesn't cause the UI to be
> Jason> unresponsive. I'm not sure if we are going to have that much
> Jason> that warrents such attention.
> 
> 	Espescially if we provide status reports and are responsive to
>  user actions (handling signals, x events, etc). Though not enough by
>  itself, the UI is a fairly compelling argument for threads (in my
>  line of work, we generally pull out the user interface to the client
>  ;-). 

It's hard to say how usefull it will be. What I am thinking is not
making very much thread safe (and probably thread aware) but just the
widget lib so a thread can be forked off and preform some simple dialog
updates asyncronously. 
 
> 	I think we should decide on this sometime soon, since as soon
>  as I get some of these boxes unpacked which are threatening to topple
>  over on top of me, I'd like to get some action on the ordering front,
>  and if we are going with threads, we should use a lock class, with
>  derived classes like read/write lock (get read lock, release read
>  lock, get write lock ...); and this shall impact the rapid prototypes
>  I like to use in the process of writing the real code.

I don't want to use thread safety or any other thread things for pkglib.
If the client wants concurrent access to a pkgLib structure or routine
then it is going to have to use locks itself.
 
The only reason the widget lib would want to be thread safe is because
it's not possible for the client to wrap any locks around the classes.

> 	Oh, I also think I need to have somehing analogous to sets or
>  lists, with possible ordering of elements (kinda like perls
>  associative arrays). (build up quick lists like: packages to be

STL maps (based on red-black tree's) are like this, but you may not need
them, it depends on your algo. I think the way it will work out will not
require much supporting structure other than the cache stuff. 

Because a large number of routines are going to need to associate a bit of
data with a package or version I belive I will add a 'user data' field to
those structures so they are not forced to deal with large cumbersome
containers to store their state. 

Jason