Multithreading in twinBASIC
We may not have the syntax to write multi-threaded code yet, but that can't stop us from creating multiple threads in the twinBASIC Debug Console.
One of the promised features of twinBASIC is the ability to create multithreaded applications. We can't yet write multithreaded code in twinBASIC, because Wayne has not settled on a syntax to support it. However, that's not about to stop us from testing it anyway.
Launching new threads from the Debug Console
Wayne is teasing us with a small taste of the multithreading goodness to come. We can prefix Debug Console commands with a tilde (
~) character to execute that command in a new thread.
The Test Code
This is nothing complicated. We'll use the Sleep API to sleep for a given number of seconds before printing the passed string to the Debug Console:
Module HangingOnByAThread Public Declare PtrSafe Sub Sleep Lib "kernel32" _ (ByVal dwMilliseconds As Long) Sub ThreadBear(SleepTimeInSeconds As Long, _ Character As String) Sleep SleepTimeInSeconds * 1000 Debug.Print Character End Sub End Module
To prove things are running on separate threads, we'll call the same function multiple times with descending sleep lengths.
Here are the function calls:
ThreadBear 10, "Goldilocks" ThreadBear 7, "Baby" ThreadBear 4, "Mama" ThreadBear 1, "Papa"
If we call these four functions in rapid succession, we get an error message:
If we prepend the tilde character to calls two through four, then all four calls will be running simultaneously and will finish independent of the other threads:
Some bugs to work out
One thing to be aware of is that there does not currently seem to be a way to remove these threads when we're done playing with them.
If you right-click on the thread in the Call Stack and choose "Terminate Thread," you might expect that thread to go away. Or, at the very least, to stop running. That does not appear to be the case at the moment:
Despite the current limitations, the possibilities of this new feature have already got my mind working. I feel like we are at the dawn of a new era for Visual Basic programmers. The future looks bright indeed.