BRL: not able to wrap multithreaded lib
BlitzMax Forums/BlitzMax Programming/BRL: not able to wrap multithreaded lib
| ||
| Grrrrrrrrrrrrrrrr, I am working on wrapping RakNet (network lib) for BlitzMax, and I just realize that this is IMPOSSIBLE! First of all, RakNet compiles only with MingW 5.x wherease BlitzMax uses MingW 3.x (and I don't understand why we don't migrate to 5.x) (see http://www.blitzmax.com/Community/posts.php?topic=64023) But the main reason why it's impossible is because RakNet is a MULTITHREADED library! Yesterday, I realized that RakNet was completely broken in DEBUG mode, whereas it was working OK in release mode (same code). You got exactly the same problem with the module axe.PortAudio which DOESN'T WORK on debug mode (the program crashes after 15 seconds) (yes, PortAudio is also threaded). (off course, it's impossible to release a product which is not working in debug mode!) So the ONLY WAY now to have RakNet is to use a DLL, but please say bye-bye to the 'cross-platformity' of this lib. I think this is very sad to have a cross-platform language like BlitzMax but to be obliged to run other libs with DLL only!!! so, question for BRL: is there a way now to deal with including multithreaded source code?? OR will there be a way in the near future?? |
| ||
| There are two examples in the mod source you may want to investigate, win32timer uses a postthreadmessage as a polite way to notify a blitzmax app of an event from another thread. The other is freeaudio which uses a simple circular buffer to feed data (the writing thread updates the writepointer and the reading thread updates a read pointer until it catches up to the writepointer meaning they can both share a common memory pool without tripping each other up). |
| ||
| Thanks for your reply, skid, this is appreciated!! OK, I will see what you are doing with the 2 examples you gave me, see if can dig into the code and adapt this to the wrapper (but I don't want to modify the RakNet source, I only want to do that through the wrapper code). I know where is FreeAudio, but in which mode is win32timer?? I did a search on the mod folder (with micro$oft), but found nothing... |
| ||
| try brl.mod/timer.mod In regards to raknet, what exactly was the compiler error you were getting with original mingw? |
| ||
| Skid, what about migrating all BlitzMax to Mingw 5.x for the next version of BlitzMax? What would be the drawbacks?? Anyway, the compiler error is listed below (here this is compiled with dev-cpp, but the error is the same in BlitzMax since both are using MingW). Notice that it compiled with no problem with MingW 5.x. |
| ||
| I looked at postthreadmessage() in brl.timer, and I have a question: the problem between multithreads and debug mode is only for Win32, or do we have the same problem on Linux and Mac?? (I have only win32 to test). If the answer is: we have the problem on all platforms, then I can use posthreadmessage on windows only, and something else on Linux and Mac -> in that case this is too much for me and I will give up at this point... If the answer is: only on windows, then I can try to use postthreadmessage on windows to see what I can do... But I can not garantee that I will clever enough to use this function (I am not C expert :-( ) |
| ||
| I think if you add ?NODEBUG to your module you can work around the debugger problem. If prevents the compiler from emitting the debug hooks into your programming. Doug Stastny |
| ||
| or add NODEBUG to the function to enforce no debug handling on the said function. function test() NODEBUG ' ... end function Thats especially usefull on calculation or loop intense functions you know |
| ||
| So I tried: - adding ?NODEBUG at the beginning of the module gave me errors when trying to run a test program: C:/Program Files/BlitzMax/mod/ru.mod/raknet.mod/raknet.debug.win32.x86.a(raknet.bmx.debug.win32.x86.o.b)(code+0x71): undefined reference to `RN_PacketGetData' (all the import "myfile.cpp" are included in the ?NODEBUG) So the functions are not included in the *.debug.* file - adding ?NODEBUG around the extern block (eg: ?NODEBUG Extern Function RN_GetRakPeerInterface%() End Extern ) -> I am able to run my test program but there is still a problem with the RakNet wrapper, whereas it is working on release mode (so nothing changed) - adding NODEBUG after the function name (but in the extern block, as all my functions are there), eg: Extern Function RN_GetRakPeerInterface%() NODEBUG End Extern -> Compiling the module, I get a compiler error: "syntax error in extern block - expecting const, global, blah". So I can not do that in an extern block. And I don't want to duplicate all my functions to do that outside the block... |
| ||
| I think you want to add NoDebug on the end of the function / method declaration, this turns off debugging in the specified block of code. |
| ||
| Mark, this is exactly what I did and what I describe in my previous post, third point, but this is not working in an extern block apparently... Does anyone know if the bad interaction between multihreaded library and debug mode is only happening for Windows?? Or it happens for Linux and Mac as well?? |
| ||
| Well, unfortunately, I do not have the skill to mess with Windows code and thread. I looked at the 2 examples skid gave me, but I am afraid I am hitting a wall here. If anyone think he could help me to solve the problem with multithreading and debug mode (with the source), then I can give the code and explain where is the problem... In the meantime, I will wrap RakNet using a DLL instead of source code (but windows only)... |
| ||
| One thing that can interference there with debug is the far lower run speed of loops as they are debugged. If all you do is extern stuff, then there is not much you can do. But if you have BM code as well, you might try to declare those functions as NODEBUG. There is not much more I can help, as I don't use the new MingW due to its problems with MaxGUI which is needed on my end. So what I could offer would be trying to get it running in current MingW and try to extend it from there, as I would be interested in having a RakNet module (K-Netlib is nice but I don't like DLLs that much after all because for the server, linux build option is a must have and I actually don't want to program in C++) |
| ||
| No, everything is done in the C wrapper, and so the .bmx file contains only function in an extern block. I can not use 'nodebug' there. Dreamora (and even skidracer who asked me the questions), if you want the error of compilation using the original MingW, then here is the package: http://repeatuntil.free.fr/raknet.mod.rar . Install this module in the mod folder, and compile it, you will get lots of error messages (see below). Just use MingW 5.x and it compiles fine. I have really no idea why there is some errors with MingW 3.1... If you want, you can look at this and try to find a reason. Obviously, messing too much with the RakNet code is not a good idea since we want to be able to use latest version of RakNet without too much changes. Note: the wrapper is not included here, just the RakNet code version 2.52 (which is downloadable on their site). But that's enough to see the error. The errors are: |
| ||
| OK I tried it with DevC++ and the project and a GC BM compiler added. The error looks like it most likely comes from the changed behavior of C++ since MingW 3.1 was released years ago. And I would assume that it is a window only issue as only windows is using a quite outdated compiler (linux and especially OSX use quite up to date ones) ... so hopefully we will get upgraded to the actual MingW soon as well ... |
| ||
| So, your and my conclusion is: BRL, please use latest version of MingW for the next BlitzMax release! (and adapt MaxGui to compile with it) Thanks Dreamora! |
   |