BlitzMax supporting Threads?
BlitzMax Forums/BlitzMax Programming/BlitzMax supporting Threads?
| ||
| I remember something that BM did not support threads. Does BlitzMax support threads now? if so, since when? |
| ||
| It does, try this thread. since when - Mark released it a couple months back. http://www.blitzbasic.com/Community/posts.php?topic=80677 |
| ||
| It does support it, but I wouldn't bother until this is fixed. When running in threaded mode, your app will basically dump a massive log file with the same name as your executable. There is currently no way of turning this off, unless you want/are able to dig into the C code for the garbage collector and figure it out for yourself. |
| ||
| Isn't it also still officially a beta module? |
| ||
| Yep. But it hasn't seen an update in months. The only ones I've ever seen are for MaxGUI, which I don't use anyway. |
| ||
| Hmmm... i wonder. How are my chances making a good serverside for an online MMO game withouth threads? |
| ||
| Hmmm... i wonder. How are my chances making a good serverside for an online MMO game withouth threads? I don't think the overhead is worth it, unless you have a 8-16 core server with tons of memory. |
| ||
| You mean, you doubt its worht it with, or without threads? |
| ||
| With. |
| ||
| I have another one (a networking developer) claiming the oposite. He says its crucial to have multithreaded gameservers, otherwise your server is busy and all connections are waiting for it, even if its a few milisec, its redicilous, as a server must always be listening, and run its gameupdates in seperate threads. So im confused now. |
| ||
| He is partially correct (in my fairly uneducated networking opinion), but in Max, without 64-bit support, I would say a single-threaded server nest would be more efficient then a massively threaded single server. |
| ||
| if you plan on having more then a dozen(*) players online at one time, then a fully multithreaded server farm (mutliple servers with each one running a mutlithreaded server program) is a must. (*) a single threaded single server can most likely handle much more then 12, but much less then 1000 players without a problem. How much more or less I have no idea. |
| ||
| C code for the garbage collector IIRC, threaded mode is using a third-party garbage collector. The compiler having to deal with two different GCs certainly can't be helping matters. |
| ||
| I don't think you can go much wrong with threads *especially* if you have at least 2 cores or cpu's in your system. |
| ||
| IIRC, threaded mode is using a third-party garbage collector. Yeah it does. But even so I don't know how its been in Blitzmax for this long and nobody's noticed/mentioned/fixed the log file problem. Because as good as the threading stuff is (and it is), its unusable simply because of that. |
| ||
| The compiler having to deal with two different GCs certainly can't be helping matters. It's not using the two GC's at the same time. ...a fully multithreaded server farm... There are many libraries available which enable scaling-up of a parallel architecture of multiple machines, although to make it effective you will need a fibre-channel network etc :-) |
| ||
| Hi, Well, as many of you will have already noticed, a new 'threaded' version of BlitzMax is now available via SVN! This is all highly experimental and will probably take some time to get right, but bear with us as I think it's worth taking the leap into threads-land! If nothing else, it's kind of fun... (taken from http://www.blitzbasic.com/Community/posts.php?topic=80344#903246) So there could be bugs and there is a log files (such the one reported by GFK) related to the current testing approch. Since the multithreading is not OFFICIAL (*) you can use it at your risk (consider that you still need to type manually bmk makemods -a -h to re-compile all blitzmax modules to be mt compatible...unless you dont' change MaxGUI source the handle this) (*) = I mean there's not an official module if you install via setup.exe, a BETA-Module is something different... |
| ||
| Yeah but the point is, it hasn't been updated for months. BETA stuff generally gets updated/fixed/released. For somebody who knows C its probably a ten minute job to get it usable. And besides, its the garbage collector that's doing it - not the threading module itself. |
| ||
| And besides, its the garbage collector that's doing it - not the threading module itself. I'm not a C expert, but I believe that the output log files will be removed in the final version (I think there's nothing in the license - if any - complaing about it!). If you ever have seen the blitzmax' source module there are/there were some 'debuglog ...' statements commented out - it's normal during a beta stage. it hasn't been updated for months. Yes, you are right. From the SVN log file the last updated is on 25th sept 2008. But this doesn't mean that is STOPPED or unfinished. And to be honest I haven't seen to much 'bug reports or complaing or help requests' about running Multithreading code on blitzmax in the last month... Probably (my own speculation!) BRL is doing some experiments WITH Max3d and Threads.mod... Consider when Mark posted something in his own worklog: we have no more news about anything, but this is normal. |
| ||
| It's not using the two GC's at the same time. I didn't say it was using both at the same time. And besides, its the garbage collector that's doing it Is this a bug in the GC itself or Mark's implementation of it? it hasn't been updated for months. When the official word for support is "figure it out for yourself". You can't hope for bugs or issues to be addressed in a timely manner. |
| ||
| Is this a bug in the GC itself It's not a bug, it's just what it does. For somebody who knows C its probably a ten minute job to get it usable. Probably less. |
| ||
| When the official word for support is "figure it out for yourself". You can't hope for bugs or issues to be addressed in a timely manner. That was a comment about Linux in general, not BlitzMax. |
| ||
| And to be honest I haven't seen to much 'bug reports or complaing or help requests' about running Multithreading code on blitzmax in the last month... Well, there's mine. Which is definitely there, and definitely needs a looking at. Is this a bug in the GC itself or Mark's implementation of it? No idea. It's not a bug, it's just what it does. Why would I want an endlessly growing log file full of warnings about garbage collection? When I compiled Magicville in threaded mode, even though I wasn't actually using any threading it still racked up a 100k log file in less than a minute.What if somebody for some strange reason plays my game for several hours? Full hard drive? |
| ||
| I agree with Brucey, its not a bug, just a *feature* that needs a toggle. |
| ||
| "months" is a bit steep... threads.c was last update Nov 9th. |
| ||
| "months" is a bit steep... threads.c was last update Nov 9th. As I said earlier, its not the threading module, its the garbage collector. |
| ||
| I think it's worth bearing in mind that the thread module is clearly described as "highly experimental", and only available in the SVN release, so it's hardly ideal for commercial releases anyway. However, doing this should stop the log file being created -- it works here anyway: 1) Back up "brl.mod\blitz.mod\bdwgc\misc.c"; 2) Open misc.c in a text editor and go to line 841; 3) Replace the GC_write function with the code below:
int GC_write(const char *buf, size_t len)
{
}
(Alternatively, just manually comment out everything between the outermost { and } lines within GC_write, so you can easily go back.) Now save misc.c, open a command line and type bmk makemods -h. Re-run your program and there should be no more log file. |
| ||
| Thanks James - that works perfectly. :) |
| ||
| Yay! |
| ||
| This threading stuff is the dog's wossnames. You have to make this an official module ASAP. |
| ||
| Hmm, Its been decided that the server will be designed on the TWISTED framework in Python. This is a matured networking lib, and it supports ASYNC operations. |
   |