Multithread Support on the ToDo-List?

[Halan]

the title says it all

greets,
halan

[hybrid]

So you will post some multithread support for whatever if you're done with your todo list or what's the issue?

[Phant0m51]

I believe Halan is asking if Multi-thread support is on the Irrlicht Dev team's to-do list.

[CuteAlien]

It's still not a question. Just some examples what it could mean:

- Irrlicht will get a wrapper to make creating threads plattform independent
- Parts of Irrlicht will be made thread safe (and which part? Baseclasses, GUI, Rendering, Fileloaders, or just everything?)
- You can use Irrlicht in a multithreaded application (you can do so already)

I guess there could be more possibilities. Is there a specific problem in combination with irrlicht+multithreading?

[Halan]

im sorry i thoguth my question was clear enough.

i read in the forums that irrlicht is not thread safe and that for example that you cannot use a second thread to load a mesh or a scene node in the scene/ram. and my question is if this will ever be possible...

greetings,
halan

[CuteAlien]

Hm, i see. Yeah, this would not be threadsafe to do.

Out of curiosity i just checked for the .obj loader how much would have to be changed for that. I think if someone really needs that he would have to look after the following stuff:
- How to handle the workingdirectory in CFileSystem.
- The stuff that happens in Device::getTexture
- Adding of the mesh at the end (after loading)

I guess changing the textureloading would be some work as a lot of stuff would have to be checked for that.

[hybrid]

That's indeed a rough estimation of what has to be done. As said several times before. But, a better parsing would help much more. Changing to MemoryReadFile and fixing some data handling is the way to go. If you want to do multithreading use it for the physics engine. Or buy an SLI card and use multithreaded rendering for free.

[niko]

I also thought it would be a nice idea to make the zip file reading threadsafe. Useful if you are using it together with an audio engine like irrKlang, so you could add your mp3s or oggs into the same archive as well and don't need a separate one.

[not_a_commie]

The Boost library already has cross platform threading in C++, and a darn nice implementation of it as well. I don't see a need to add a cross platform threading library to Irrlicht.

[hybrid]

Making a library thread-safe is a completely different thing. It would not even need a threading concept. The task instead is to make the internal structures of Irrlicht aware of the possibility that multiple threads might invoke functions in parallel.
Adding threads inside Irrlicht is probably not necessary as most functions which could be threaded are user-invoked such that the user would have to handle this on his own.