Re: Threads

[Manoj Srivastava <srivasta@datasync.com>]

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? 

Jason> There are a few other instances where using a thread might
Jason> clean things up, esp in the dowloading section, it's hard to
Jason> say till you arrive :|

	I'd hesitate to advocate the use of threads until there is a
 clearcut advantage to doing so. 

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
 ;-). 

Jason> I've done a fair amount with threads before, but generally only
Jason> in cases where there is a single point of synconization, I'm
Jason> not sure what a full widget set would end up being like if it
Jason> were thread-safe/threaded.

	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.

	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
 installed, packages that are targets of pre-dependencies, list of
 packages that are install now, etc). membership tests are often
 heavily used in these lists.

	My usual answer to this has been efficient implementations of
 red-black trees, which can be built up and torn down fairly fast (on
 a fast alpha, I had a thread safe implementation that did several
 million operations in under 10 seconds)

	Is there a need for this outside the potential use I see
 within the ordering code? Do people think there is a better way of
 doing random access lists? (I think that threading another linked
 list is slightly cumbersome).

	manoj

-- 
 "It's a fine world, though rich in hardships at times." Augustus
 McCrae
Manoj Srivastava               <url:mailto:srivasta@acm.org>
Mobile, Alabama USA            <url:http://www.datasync.com/%7Esrivasta/>