SQF Threading?

[Nutty_101 0]

Ok, here is a quick question for some people who might have an idea. On the Wiki - ExecVM page Giova says the this command is really a thread handler. I am going to assume this is wrong and a separate thread is not created as i can cause serious lag on the server when running heavy scripts under this command. Does anyone know if this was even meant to be a separate thread?

[5133p39 14]

i don't know anything about the inner parts of ArmA scripting engine, but i am using spawn to run my scripts, and it works nicely (especially if you make something so "stupid" like me - running the same script 100 times in parallel).

Although i doubt there is some major difference (in executing the code) between execVM and Spawn, you could try to use Spawn instead and see whether it runs better.

And, of course, don't forget the possibility that there could be something wrong with your scripts.

[Nutty_101 0]

Yeah. The games thread count never increases no matter how many execvm's i spew off so i think i might have answered that question to myself. Laugh.

[5133p39 14]

Yeah. The games thread count never increases no matter how many execvm's i spew off so i think i might have answered that question to myself. Laugh.

a "thread count"

[mr.peanut 1]

So what the hell is the difference between execVM and spawn?

[5133p39 14]

So what the hell is the difference between execVM and spawn?

The only difference i know about is that execVM will first compile and then execute the given script, instead of the Spawn which is expecting already precompiled code (compile, preprocessFile).

The Spawn is more suitable for executing the script more than once, because you can compile it only once and then just "spawn" it how many times you want, whenever you want.

[Synide 0]

yes, nutty... i don't think giova was referring to a Operating system thread being created as... well it just doesn't.

i think what he's meaning is execVM & spawn both create a branched in-game 'scripting thread' which runs async.

i think you'll find he was using the term 'thread' in a general way...

[Nutty_101 0]

Oh well. Just was all bummed out after reading that thinking it would be a great method to do some heavy processing. Laugh. Thanks everyone.

[UNN 0]

Quote[/b] ]Oh well. Just was all bummed out after reading that thinking it would be a great method to do some heavy processing.

I think it is a great method to do some heavy processing. Imagine one script that handles a hundred soldiers. As opposed to a hundred versions of the same script, that handles each soldier.

IMHO the latter is a better solution, as it helps spread the load. The new commands do help in that respect. But lets assume this is more theory than fact, on my part.

[Nutty_101 0]

Quote[/b] ]Oh well. Just was all bummed out after reading that thinking it would be a great method to do some heavy processing.

I think it is a great method to do some heavy processing. Imagine one script that handles a hundred soldiers. As opposed to a hundred versions of the same script, that handles each soldier.

IMHO the latter is a better solution, as it helps spread the load. The new commands do help in that respect. But lets assume this is more theory than fact, on my part.

Yeah, but i would be locking up that thread via external applications. That way i could freeze one thread while the game kept going. That's really what i was wanting. At the moment I have a map that i am working on and it references almost 30 different SQL tables, two websites via HTTP and a vast amount of memory sharing with another server running in a separate process. Thus why i was hoping a thread was unique.

[Synide 0]

I'm with you on that note UNN... but I'm seeing a lot of 'script' about where people are using 'call', 'spawn' and 'execVM' in inefficient ways...