Threads seemed like magic to me when I learned about computers. And when I learned a little about programming - still magic.
I can't do magic, I've tried.
I also tried to learn c++ - multiple times. Assembler was easier for me. Spent a lot of money. Just wasn't for me. I had some kind of mental block.
I also had too many questions - like:
Why aren't there strings? At some point, something has to come out. A person is going to read it.
How can you make something that is so easy to screw up? If your life depended on it, you would NOT make the traffic signals only semi-tones
of different colors. And you wouldn't have two hundred flashing lights, all at only slight angles from each other at every intersection.
So easy to make a mistake that some serious security bugs have hidden in extremely well-used and reviewed libraries for - LITERALLY - decades before someone
caught the error. When the difference between = and == can mean a hole in your security that a tank could roll through.
Did I mention, no strings?
Well, now there is strings. Still not so easy to use, though.
When I picked up programming again, after 30 years, threading wasn't magic anymore. c++ isn't a mystery, either, and I can do it. But why ask for the pain? Now - to FB and threads.
Threading is useful when:
you want to do a LOT of the same thing, almost, and they aren't tied to each other, or maybe they are
you have a lot of things to happen, each happening based on a trigger, maybe before, maybe after - - who knows what - not always the same, and some maybe at the same time
when you have a lot of things waiting on external processes
when you want to have a job going that can take care of itself, and you don't want it in your face all the time, but don't want a separate program.
And whatever they tell you, you DON'T need a multicore processor to take advantage of multithreading. We would never have had any computers if that was the case.
A thread is like a mini program: you ALMOST get a tiny program with everything that was in the main program - which is the largest problem to keep aware of.
Any data that traveled into the new thread may become stale and out of step with the main. Any data you may want to read or write may not be accessible. And
when it IS accessible, you have to worry about who gets to write, and when, to avoid overwriting other, good data.
FB
The examples in the wiki don't make sense: you control the thread from the main, not the other way around. Pritchard wrote a framework for controlling
threads that makes sense. Very instructive. Search for CThread. Unfortunately, it will only control one other thread. It needs to be radically altered to handle more than one. I did that. Topic for another day.
There is no good tutorial on threads, thread management, what you can do that makes sense, and (my complaint about FreeBASIC) no advice on what to stay away
from in the help or wiki. Everyone is always asking for help, and there are good people to help. But you are on your own. Frustrating.
What is thread safe is fairly well known, but not listed anywhere. It should not be rocket science.
Search the forums - always - before asking a question. There are many, many discussions of threads. And many very common mistakes made.
I will not get into using threads in games. (Yet?)Later: yes, threads, no sweat. No games.
This will take some time to get all recorded. So ... little at a time ...
---------------------------------------------------------------------------------
pointers - BASIC shouldn't need pointers. BASIC wasn't intended to do threads. FB does - and you need pointers.
Read the Programmer's Guide and the Community Tutorials - several times. Practice.
Somewhere you will find that you can make sub and function pointers. THREADCREATE takes an any pointer. Only.
Keep ALL I/O in one thread.
Allow time for any printing to occur if your thread has output. You can move fast enough that your thread can die before the printing has happened, and orphan a task sent to the OS. Not nice. A simple THREADWAIT can do it.
A pointer to a UDT can send large amounts of data - or commands - to the thread without *moving* large amounts of data.
Threads are easy for me, now. Ask. DO NOT ASK in the forums. There is at least one guy who really knows his stuff, and what he learns from the classical teaching about programming. HOWEVER ...
He also will make every example far more complex than needed to illustate the question asked. He doesn't have flexibility. He defends the sometimes poor documentation too fiercly. He is NOT
an advocate of making things easy to find in the docs. It is YOUR job to search every possible link to find the answer to the question.