FB II Compiler







Disk I/O














Made with FB


Understand thread

Threads are the coolest things. Technically speaking, a thread is a process that runs just like a program (for all intents and purposes a thread is a program). However a thread can be preempted by other threads and can run asynchronously along with other software without having to manually 'give up a slice of processor time'. A good example of a thread on the MacOS is the Finder's ability to copy more than one thing at a time. Each copy window is a thread. The Finder in MacOS 8 is fully multithreaded, which means just about everything the finder does uses threads.

Your program can 'spin off' a thread process to handle some task asynchronus to your main program execution and your main program won't have to worry about maintaining the process or check if its done or not.
The thread will automatically give up time to your application.

When might you use this? How about times when your event loop has become so complicated because of various processes that *might* be running and have to be handled? Here is a good example Staz once used in PG:
  IF gPrinting THEN FN PrintNextLine
The theory here is that if the app is printing, you can still use other features of the app while the print data is sent in small chunks at a time.

A thread could free up a lot of programming headaches here. You could spin off a thread process and within the thread code you can print the document from start to finish without worrying about giving up time or calling handlevents. The MacOS will interrupt and resume this thread at regular intervals so that your program still responds to user input.

Threads help you organize your program into identifiable processes which can all run at the same time as needed. This makes it much easier to write programs that may have to do many things at once. It also makes program design easier.
Imagine this example:
  res& = _nil
  x = x +1
  res& = FN GET1RESOURCE(_"PICT",x)
  IF res& THEN FN Process24BitImage(res&)
UNTIL res& = _nil
Now let's say we process something with maybe 100 images and the process runs a really complex filter over the graphics. Your program would probably be unusable while this is happening because there is no HandleEvents in this loop and the loop takes a long time to finish. In fact, the entire Mac would be tied up. To fix this you'd have to do something like above and process one image at time. You'd also need lots of variables to keep track of progress, the image in use, etc.

If this code were executed within a thread you wouldn't have to worry about any of this. The code would work as is without completely tying up the Mac or your program. A thread could have an infinite loop within it and not actually use all processor time. The thread itself however would become 'blocked'.

There are limits to this of course since most toolbox calls were not written with threading in mind, many synchronous calls will block a thread for at least a short period, however main program execution will not be greatly affected.

The whole reason I brought this question up was because I've been writing a full fledged chatline in Java (not an applet, a real application), and it uses threads for all kinds of things, and I wanted to try to do the same in FB. Every window is a thread, every user connected is serviced by a thread, etc.
Derek Smith