[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Threads



On 20 Oct 1997, Manoj Srivastava wrote:

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

Well, there is the main thread and the thread that dies. The thread that
dies would look something like:
   void Thread(void *)
   {
      for (.... File++)
      {
         GenerateCache(File);
         UpdateDialog(File);
      }
      KillDialog();
   }

The main thread would be somehow notified after 'KillDialog' (Widget
notification?) runs and then continue on with whatever it was doing.
Otherwise bringing up a dialog is considerably complicated because of the
way X runs -- may not even be worth implementing. 

This is abou the total extent of why I would want to use threads. For
routines of varying purpose, but generally formed like the above.
 
> 	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). 

Well, I have used this in the past, but it won't work in this case because
of the redraw syncronization required with X, and come to think of it the
SLang version won't work so well either if the select loop isn't run in a
timely fashion.

During the above operation the entire main window would be placed into a
'blocked' state (no input). Also the cache generator is a 'safe' routine,
it doesn't use globals/statics in any way so in this example it's
perfectly safe.

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

Hm, this is usually how I end up using threads. It is complicated to make
a routine non-blocking and much simpler to use a thread (using independant
structures as much as possible) that does it and singles the main routine
when it is done. 

The -only- reason I worry about thread safety is that in this case I
cannot advoid the thread wanting to make changes to the widget. This can
either be done through a complex signaling process with the main thread or
a locking+signaling process.

I -really- don't know how the widget lib will thread.. It will likely have
to be a combination of locks and signaling techniques to make it work and
the threads will likely have vastly restricted abilities.. 

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

What sort of callbacks do you mean in this context?
 
> 	Fair enough. Then you can't update dialogs in pkglib. It is
>  one thing to provide a sensible thread safe wrapper around non-thread

Pkglib isn't even aware dialogs exist so this isn't a problem as far as
I'm concerned.

Basically, I don't have any plan on how to implement a lengthy operation
and allow it to draw on the screen, or have the widget set remain
responsive. If we don't use threads this is going to result in some very
strange code, or permanent lack of features, like status dialogs :>

I wish I had time to make some nice docs about the widget lib, it would
clarify this... The basic way the widget lib works is through a select
loop that is always where the program idles. The time spent processing
events as they arrive at the FD's is very small and should never end up
blocking if the UI is to continue to redraw, ftp's continue to get their
data, etc

To implement a linear open dialog, do operation, update, close dialog
sequence would somehow require recusively calling the select loop at key
times and syncronizing with the events as they flow down the pipe. This is
pretty much what windows does you put code like
    while (PeekEvent(..))
        HandleEvent(..)
So the user can click the Cancel button :P

I could quite happily fork(), create a pipe and have the two bits chat
between each other like that, but somehow it seems simpler to use a
thread, or a thread with a pipe ;>

Jason


Reply to: