Re: Threads

[Manoj Srivastava <srivasta@datasync.com>]

Hi,
>>"Jason" == Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> writes:

Jason> On 20 Oct 1997, Manoj Srivastava wrote:

>> Hi, "Jason" == Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> writes:

>>  What does the dialog do? (I'm confused here). Can it be done with
>> timers?

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

	If you just start a thread that does one task, and dies, then
 only minimal synchronization is required. But your dialog thread has
 to interact with the backing store genrator thread, and you have to
 introduce synchronization in both routines. 

	As an alternative, may I suggest that we try to build in the
 dialog into the cache generator (maybe as an anonymous hook function)
 that is called periodically (the trigger points may be decided
 elsewhere). 

	You will *have* to take special action in the generator thread
 to communicate with other entities; this other action may well be the
 dialog update function.

	This is how most update displays are done.

	Professionally, I would strongly advocate not using threads
 for this.

Jason> It is not easy (or likely desirable) to cook something up to
Jason> support cases like this without a concurrency through processes
Jason> or threads.
 
	I think I disagree. I would say that is is undesirable to use
 threads in these cases, and I have been using pthreads since draft 4
 days (back in 1990, I think that's what the draft we used).


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> It's hard to say how usefull it will be. What I am thinking is
Jason> not making very much thread safe (and probably thread aware)
Jason> but just the widget lib so a thread can be forked off and
Jason> preform some simple dialog updates asyncronously.

	I think call backs are the way to go, rather than full thread
 awareness.  

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

Jason> I don't want to use thread safety or any other thread things
Jason> for pkglib. If the client wants concurrent access to a pkgLib
Jason> structure or routine then it is going to have to use locks
Jason> itself.

	Fair enough. Then you can't update dialogs in pkglib. It is
 one thing to provide a sensible thread safe wrapper around non-thread
 aware code, it is another to safely use threaded libraries (think C++
 exceptions and destructors). 
 
Jason> The only reason the widget lib would want to be thread safe is
Jason> because it's not possible for the client to wrap any locks
Jason> around the classes.

	Great minds ...

>> 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

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

	I'll defer this to a later date when I have more time.

	manoj
-- 
 Man weeps to think that he will die so soon; woman, that she was born
 so long ago.  -- H. L. Mencken
Manoj Srivastava               <url:mailto:srivasta@acm.org>
Mobile, Alabama USA            <url:http://www.datasync.com/%7Esrivasta/>