On 20 Oct 1997, Manoj Srivastava wrote: > Hi, > >>"Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> 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
