WitchLord already pointed out that he doesn't want to use external libraries in AngelScript, and to someone like me that is very important. The main issue for me is licensing (though, Andreas may have issues with being dependent on outside source code). You don't want to be mixing different open source licenses, it will make things very confusing.
I know Andreas wants the game industry to adopt AngelScript, and one of the sticking points, unfortunately, is open source licensing. The license AngelScript uses is great, however, there are still the indemnification issues, and that is what scares professional game developers and publishers from using open source libraries, even if the license the library uses says "go ahead!!!".
Say a technique was used in AS that (unknowingly to Andreas) is a patented technique (ugh, software patents). If the patent holder finds out AngelScript is violating the patent, they could go after anyone who uses AngelScript and sue them. Open source licenses typically do not indemnify the user because no money exchanges hands, the creator of the library doesn't also want to take on that kind of legal burden too. This obviously scares publishers.
So, this is why I bring up the use of external libraries as scary.
As for the thread topic, has anyone done any profiling to see exactly where the performance hit is on a multiple processor system? I don't understand the point is changing something that might not be the cause (unless it is verified).
Improved thread local storage for angelscript
looks like a very neat threading lib indeed, thanks.
WitchLord, some questions and discoveries about thread safety and AS:
All the AS threading stuff atm is windows only anyway. Do you forsee any hassles with running 1 engine per thread and sharing nothing between engine instances without the threading support?
If not then AS is fine for low latency as it is (or with USE_THREADS undefined on windows). Threads with no synchronisation talking to each other via lockfree message queues with the realtime threads raised to realtime priority and minimising system calls is the normal way of doing things.
After studying the AS code I think it's likely impossible to make lockless via atomic ops due to the garbage collector, I didn't realise AS had a system of deferred lists and incremental collection with cyclic reference count busting very cool code! How tested is the GC in multithreaded situations? I don't fully understand what would happen using the same engine across multiple threads, it seems only one thread could run the GC?
WitchLord, some questions and discoveries about thread safety and AS:
All the AS threading stuff atm is windows only anyway. Do you forsee any hassles with running 1 engine per thread and sharing nothing between engine instances without the threading support?
If not then AS is fine for low latency as it is (or with USE_THREADS undefined on windows). Threads with no synchronisation talking to each other via lockfree message queues with the realtime threads raised to realtime priority and minimising system calls is the normal way of doing things.
After studying the AS code I think it's likely impossible to make lockless via atomic ops due to the garbage collector, I didn't realise AS had a system of deferred lists and incremental collection with cyclic reference count busting very cool code! How tested is the GC in multithreaded situations? I don't fully understand what would happen using the same engine across multiple threads, it seems only one thread could run the GC?
Lorien Dunn
you are right about patents midnite, although the OSDL/Linux foundation has a patent war chest at their disposal and funds they've pledged to use in defense of all linux software, but what a pain in the backside. I don't do patent searches due to increased liability in cases of known patent violations, it's best not to know.
Lorien Dunn
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement