mastaraymond
2010-01-14 06:05:03
I've seen several suggestions related to Multithreading, therefore I thought it would be nice to make a topic about what is and what is not possible regarding multithreading.
First you must understand how a script is run. We use an interpreter which works quite simple: it reads a line, does what it has to do, read the next line, does what it have to do etc..
Therefor it's not possible to make multithreading since it can't just jump to another line somewhere else in the script (which is what 2 mainloops basically is).
There are several ways of doing a kind-off multithreading:
1) Something like SetTimeout, a solution where every x-minutes your function gets called.
2) Run multiple scripts - asynchronously.
3) Let the compiler call a specific function after it interprets x-amount of script lines.
4) Create a seperate interpreter for every thread you run.
Now option 4 needs a bit more explanation:
Say you want to run "procedure MyThread" in a different thread. You then would create a new thread in Simba, create a new interpreter and let it interpret MyThread only. The problem with this is that all of the global variables etc are completely 'disconnected'. Therefore it would be the same as running two scripts asynchronously. However! I might be able to connect the global variables in this new thread to the 'mainthread', and make a real kind of multithreading. This will come with some security risks, but yeah it might be worth a try.
Kyle Undefined
2010-01-14 08:56:58
Option 4 is what I've been thinking about, I asked Wizzup? if it was possible for one tabbed script to access variables from another tabbed script. I think if we took that approach, that there should be a limit of 2 threads per Simba. Also, a way to see if each thread is active or not, so if one ends then the other will too.
~Camo
mastaraymond
2010-01-14 10:05:34
From: Camo Developer
Option 4 is what I've been thinking about, I asked Wizzup? if it was possible for one tabbed script to access variables from another tabbed script. I think if we took that approach, that there should be a limit of 2 threads per Simba. Also, a way to see if each thread is active or not, so if one ends then the other will too.
~Camo
It's not tabbed at all, it will be 'actual' multithreading, just inside Simba there will be a kind of tabbed approach.
Kyle Undefined
2010-01-14 11:25:33
Oh, well that's even better I suppose, sounds like a nice idea to me.
~Camo
mixster
2010-01-14 14:01:25
I would prefer not to hide anything by running it in a hidden thread - I see no problem with giving it a visual tab so people can at least see what it's doing (even if it can't be stopped) as I would think there is more of a security risk if the thread is up to no good if it can't be seen. Regarding sharing variables, I would prefer it if perhaps there was a method of sending data between the two reliably and safely, but would rather not have variables directly shared. In terms of where multithreading of one type or another would be most useful, it's really only the current players nick where I can see it needing to share data - everywhere else I would say multithreading is more for observation that doesn't require knowledge about the person or the like.
mastaraymond
2010-01-14 14:24:10
From: mixster
I would prefer not to hide anything by running it in a hidden thread - I see no problem with giving it a visual tab so people can at least see what it's doing (even if it can't be stopped) as I would think there is more of a security risk if the thread is up to no good if it can't be seen. Regarding sharing variables, I would prefer it if perhaps there was a method of sending data between the two reliably and safely, but would rather not have variables directly shared. In terms of where multithreading of one type or another would be most useful, it's really only the current players nick where I can see it needing to share data - everywhere else I would say multithreading is more for observation that doesn't require knowledge about the person or the like.
What you on about, what's wrong with multithreading being in 1 tab/script? I see absolutely no security risk here.
Also, you want to LoggedIn to work alright in your new thread, you want the bitmaps to be 'shared', etc..
Nava2
2010-01-14 14:28:12
Perhaps put the tab in the debug box?
mixster
2010-01-14 14:47:02
I guess my view may be a bit OTT, I'm just thinking of worst case scenarios, such as person X having a function that starts a new thread and in it he downloads dodgy code to run and runs it using a third thread. Considering the user would usually only see the dodgy code if they checked the link (which is unlikely if it's a well disguised name and user X is a fairly trusted person). Unsure on whether or not method 4 would be able to take a downloaded script and run or if it would only allow in file scripty stuff to be run or what, so was assuming it could pretty much run any string.
mastaraymond
2010-01-14 15:29:14
From: mixster
I guess my view may be a bit OTT, I'm just thinking of worst case scenarios, such as person X having a function that starts a new thread and in it he downloads dodgy code to run and runs it using a third thread. Considering the user would usually only see the dodgy code if they checked the link (which is unlikely if it's a well disguised name and user X is a fairly trusted person). Unsure on whether or not method 4 would be able to take a downloaded script and run or if it would only allow in file scripty stuff to be run or what, so was assuming it could pretty much run any string.
What? Option 4 is just meant to execute a script-method in a several thread ->
program New;
procedure mythread;
begin
while Statement do
CheckRandoms;
end;
begin
CallnewThread('mythread');
repeat
DoStuff;
until NotLoggedIn
end.
mixster
2010-01-14 15:32:43
Oh that would be fine then - it seemed like it would be a lot more powerful.
mastaraymond
2010-01-14 16:06:12
From: mixster
Oh that would be fine then - it seemed like it would be a lot more powerful.
Hehe, the script above is the most powerful multithreading you're gonna get ;).