NG - threading on by default

Started by Brucey, June 19, 2017, 08:48:04

Previous topic - Next topic

Brucey

Hey ho!

Currently to use the threading stuff in BlitzMax, you need to do a separate build to enable all the functionality - and in legacy BlitzMax use a different garbage collector.

With NG, we use the same GC regardless of whether your app is threaded or not.

So I am wondering, for NG, why we need to provide a separate build option just to gain access to thread functionality when it could just as easily be included as part of the "standard" build?


Are the any particular reasons why it would be a bad thing to enable threading by default in NG?

col

I don't see any major reason not to have one build system in NG.

I can only see possible hiccups maybe if someone is using the threaded compiler switch to include other things related to their threading code, things that may be different to their single threaded build. I would think they would be need some simple touching up but I doubt it would be a big issue.

I see it as a good move personally.
https://github.com/davecamp

"When you observe the world through social media, you lose your faith in it."

therevills

Is there any possible negatives with having the threading build as default? What is added to the artifact to make it "threaded"?

col

QuoteWhat is added to the artifact to make it "threaded"?

In NG... nothing I'd guess, other than the allowing the functions/types to be used.
Brucey is saying that the only difference in the legacy version was different garbage collectors. In NG that difference doesn't exist so you get the same garbage collector for threaded and non threaded builds.
https://github.com/davecamp

"When you observe the world through social media, you lose your faith in it."

GW

I can't remember ever a seeing a difference in builds between single threaded and multithreaded ng projects.
How would this be handled in the BMK arguments? 
Right now Blide works with NG in building 32bit apps, but blide doesn't expose what it's sending to bmk, so if the args change too much, it will break blide, and that would be a very bad thing.
So if you changed bmk to make the '-h' argument mean nothing, I suppose that would work.

Brucey

Yes, it would be easy to enable threaded and do nothing with -h, and perhaps show a message to say that threading is now always enabled on NG.

I was coding a basic server for a network/socket tutorial today, and it was annoying to have to go and switch to a different build just because I wanted to add a thread pool - I'm lazy, and my other programming languages don't require me to ask nicely to play with threads.

Rick Nasher

#6
It's unlikely, but perhaps threading isn't always supported/useful on each and every current and in future supported platform(for instance simple IoT devices)?
In that respect I'd say reverse the switch so that it means 'on' by default, but leave the option to disable it in case of unforeseen problems and maximum versatility?




_______________________________________
B3D + physics + shaders + X-platform = AGK!
:D ..ALIENBREED *LIVES* (thanks to Qube).. :D
_______________________________________