SRL Archive - Suggestions

Hey there,

I've had this idea for some time now. I think it's very possible to introduce multi-threading to Simba. Basically, we just have to implement something similar to JavaScript's webworkers. This means that the thread code will have to be loaded from a file/string (perhaps the same file?), but I don't think that's a major issue. Communication is done through messages, so sending arrays will be a bit hard (without pointer support), but strings/integers are easy to share.

What do you think? Is it worth it? And does anyone feel like implementing it? ;)

Nielsie95

Would it be possible to release a completely separate (beta) version of this?

Why? Of what? ;)

Maybe I don't fully understand, but does this not imply modifications to Simba itself?

Yes, it means that there will be an extra class exported. But it's only a concept at this point and I want to know what the general thought is about this and if someone is actually willing to implement it.

From: nielsie95
Yes, it means that there will be an extra class exported. But it's only a concept at this point and I want to know what the general thought is about this and if someone is actually willing to implement it.

If by implement you mean find applications and uses for it, then yes. I can think of two really good ones off the top of my head: Randoms and Painting Debug. If by implementing you mean doing lots of work then im out! ;P jkjk

I would LOVE multi-threading in Simba!

From: Drakan
If by implement you mean find applications and uses for it, then yes. I can think of two really good ones off the top of my head: Randoms and Painting Debug. If by implementing you mean doing lots of work then im out! ;P jkjk

I meant implementing it in Simba. So creating the functions that do the work behind the scenes. I don't think it should be that hard, but there will probably be a few surprises along the way :p

From: nielsie95
I meant implementing it in Simba. So creating the functions that do the work behind the scenes. I don't think it should be that hard, but there will probably be a few surprises along the way :p

I vote wizzup.

From: Drakan
I vote wizzup.

This reminds me when something had to be done in my ex-class and we always "democratically" chose the one not being in the classroom.
So quickly vote till Wizzup? sees this :sasmokin:.

p.s.: I vote for him too.

From: Sabzi
This reminds me when something had to be done in my ex-class and we always "democratically" chose the one not being in the classroom.

I laughed.

Support, multithreading would open up a lot of possibilities to improve Simba scripts.

I don't see why everyone insist on a separate thread for random handling.
If you want to do it like the Java bots just have a loop with findnormalrandoms at the end. Its the same sort of thing. Unless you can freeze the script thread at any time and give control to the random thread there is no point.

From: noidea
I don't see why everyone insist on a separate thread for random handling.
If you want to do it like the Java bots just have a loop with findnormalrandoms at the end. Its the same sort of thing. Unless you can freeze the script thread at any time and give control to the random thread there is no point.

I think that's the point. Using the Thread.Pause features.

From: noidea
I don't see why everyone insist on a separate thread for random handling.
If you want to do it like the Java bots just have a loop with findnormalrandoms at the end. Its the same sort of thing. Unless you can freeze the script thread at any time and give control to the random thread there is no point.

Who said anything about random handling?

Multithreading has a lot of different areas of where it could be used.

An idea I had a long time ago was to run the Mouse() procedure in it's own thread, making it possible to search for objects and moving the mouse at the same time

From: Zyt3x
An idea I had a long time ago was to run the Mouse() procedure in it's own thread, making it possible to search for objects and moving the mouse at the same time

Now this would be well worth it :thumbsup:

random question (might be stupid, but w/e): would adding this possibly increase how much the script uses ones processor? already people are having issues running more than a few SMARTS and such, so would adding this be worse, the same, or better for CPU performance?

random note: i do not fully understand how we would incorporate this, but trying :)

Hmm, I'm not sure how you intend to implement this… You won't be able to access anything in the script directly from the thread, so basically you'd have to be running a second script and communicate with that?

Yes, you will be running a(nother) script in another thread. Communication is done through messages (which will probably have to be stored in some sort of temporary queue). For example:

begin
  w := TWorker.Create('worker.inc');
  w.SendMessage('Some information in here?'); //Start an action by sending a message
  w.StartProc('CalculatePi', [50 (*digits*)]); //Or perhaps start an action by running a function

  //Do some other stuff

  if w.HasMessage then
    WriteLn('Answer: ' + w.PopMessage)
  else
  begin
    WriteLn('Worker isn''t done yet!');
    //w.WaitForMessage(5 * 60 * 1000); Possible wait with a timeout?
  end;
end;

The worker itself also needs a queue to store messages sent to it, so it can process them one by one. Like I said, arrays and such will be harder to pass (without pointers), but not impossible.

Yeah, I guess that would work, but it isn't very efficient at best, though efficiency has never been much of an option with pascal script…

Can't simba already run multiple scripts? And scar had 'inter-scar messaging'. Why not mash the two ideas together, and modify smart to accept commands from multiple scripts? (or go no-smart, but that… kind of defeats the point to an extent).

Moving back to the simba being able to run multiple scripts, doesn't that mean the functionality is already there to an extent?



…
And no, I don't entirely understand multithreading.

From: nielsie95
Yes, you will be running a(nother) script in another thread. Communication is done through messages (which will probably have to be stored in some sort of temporary queue). For example:

…

The worker itself also needs a queue to store messages sent to it, so it can process them one by one. Like I said, arrays and such will be harder to pass (without pointers), but not impossible.

After reading WebWorkers I was thinking it would go this way.

procedure OnMessage(Worker: TWorker; Message: TWorkerMessage);
begin
  WriteLn(Message.Content);
end;

var
  w: TWorker;

begin
  w := TWorker.Create('worker.inc');
  w.OnMessage := @OnMessage;
  w.StartProc('CalculatePi', [50 (*digits*)]);

  //Do some other stuff
end;

Now I'm not active anymore, but this is something I've been longing for since I begun scripting. Multi-threading would be a GREAT addition to efficiency, functionality and less detectability.

Three thumbs up! (Yes, I grew one just for this)

From: nickrules
Can't simba already run multiple scripts? And scar had 'inter-scar messaging'. Why not mash the two ideas together, and modify smart to accept commands from multiple scripts? (or go no-smart, but that… kind of defeats the point to an extent).

Moving back to the simba being able to run multiple scripts, doesn't that mean the functionality is already there to an extent?



…
And no, I don't entirely understand multithreading.

Yes, Simba can already run multiple scripts. The problem is having the scripts communicate and share resources such as arrays, strings, etc.

From: Dgby714
After reading WebWorkers I was thinking it would go this way.

procedure OnMessage(Worker: TWorker; Message: TWorkerMessage);
begin
  WriteLn(Message.Content);
end;

var
  w: TWorker;

begin
  w := TWorker.Create('worker.inc');
  w.OnMessage := @OnMessage;
  w.StartProc('CalculatePi', [50 (*digits*)]);

  //Do some other stuff
end;

Yeah, but I'm not sure how well Pascal Script handles this. If you're already running something (for example wait(MAXINT)), can the OnMessage be called? (Wouldn't that require multithreading? :p)

Although, you could do it like that and have an extra function ProcessMessages which handles all the new messages and calls OnMessage.

Off Topic: When could we see lape in simba as the standard?

Not sure. Imported classes are well on their way, but I'm not sure how well everything is working. Feature-wise, it's almost there, but it certainly will not replace pascal script right away.

Is there a way to make a script run another script?

@Nielsie

Are you planning on multithreading support for LAPE?

From: mormonman
I think that's the point. Using the Thread.Pause features.

Yea but thats not how they work. They cant pause at any time. The java bots (idk about rscheata/nexus) only checks for randoms at the end of the mainloop.

From: noidea
Yea but thats not how they work. They cant pause at any time. The java bots (idk about rscheata/nexus) only checks for randoms at the end of the mainloop.

Why can't you pause a thread?

You can pause a thread, but it's not a good solution for randoms. After all, how does the "script thread" know how to continue? It will just go on with what it was doing (clicking a rock perhaps). A random has side effects which a script has to take into account. RS scripts do not need threads, that's why I asked if there was any interest :)

@Yago: Simba does not have built-in support to run a script from a script.
@lordsaturn: I do not plan to add any specific language features for threads (like threadvars), but Lape is currently able to function in a multi-threaded environment.

Nielsie, Simba has OpenScript and OpenScriptEx that can be used from extensions. Couldn't they be exported to PS?

I guess that's possible, yes :)

I'm bumping this because I'd *LOVE* to have multithreading in simba.