To try that, should I remove "threads off" and put "map-threads off" as the option?

Thanks
Yeah, "map-threads off" will turn off the map threads specifically. "threads off" will turn off all threading.
Tried it with map-threads off and it took WAY longer to actually freeze. But it still froze.
Can you be more specific about the nature of the freeze? Did it cause the CPU to race or did it just stop responding?
The cpu (as reported by world.cpu) wasn't racing or higher than normal. The app just stopped responding after a certain point. I can't come up with any certain action that would have specifically caused the hang, because all of the actions we were doing were being done repeatedly during the duration of the test.
Is this easily reproducible (eg, do you need a lot of players, long hosting time, etc?) If so, if you could provide us with the game we could try it out to see if we can find where it's getting stuck.
FIREking, which game is it you're hosting? (I really hope it's not SS13.) Is there any way I could try hosting it to see what can come up in the debugger? I'm confused as to why you'd still be having trouble with threads on but map-threads off, since in theory there shouldn't be a problem with map-threads off. I've identified that there are some lingering issues with map-threads on, though.
From what I can gather it comes from the game having a large load time in Daemon/Seeker before the server begins, so any game with a large enough map and/or enough processes running at the start of a new world should cause this.

If you need an example, I could send one of you the host files for Alternate Worlds but the resources for it are quite large at the minute until I cut down the sound files.

So it might be easier to try making a new project with a large map and trying to host it.
My game doesn't have a large load time.

Lummox, another thing I noticed is that I force quit the server about an hour ago but the hub still shows the game as live.

To answer your question, the game I am hosting is a very experimental test version of Legends Online. Its asset base is very very large. Let me see if I can get this happening on something much smaller.
Yes, if you can reproduce the same problem in a demo, that would be invaluable. To be clear, we've been able to confirm an issue with map-threads on, but not with them disabled (but threads still on).
Also, would you mind telling us if your game shows this issue in the 501 release (http://www.byond.com/download/build/501)? We are really baffled as to why you are getting the issue with map-threads off but threads on, and 501 should elucidate since that simulates that setup.

And verify that it all works in the new 503 stable, which has no threading whatsoever.

Thanks!
501 was fine
Just tested map-threads off on 504 and couldn't make it freeze in two different test beds

However, in 504 it definitely crashes with all threads on, and the world.cpu always displays 8
Ok, maybe the "threads on" (but "map-threads off") is a red-herring.

I assume the stable 503.1224 works fine? That has no threading at all.

We should hopefully have a patch for 504 next week and then we can see if multithreading improves performance.
In response to Tom
Tom wrote:
We should hopefully have a patch for 504 next week and then we can see if multithreading improves performance.

Out of curiosity, is the new threading setup exchanging a slightly higher CPU load in single-player for a more scalable approach in multiplayer?

I'm noting that 503/504.1225 is generally running at around 7-8% CPU usage with nothing going on, whereas 501 defaults to 0%.
I experience this with newly started projects, not just older ones. It usually occurs when I have my pager going.
Tested the new 504.1226 build, and the threading is on with no crashing or freezing thus far...

The problem however is that world.cpu report is inaccurate, and doesn't this now raise the question that we should be able to get two cpu readings... one for logic and one for map operations?
We'll improve on that. Are you seeing any performance difference? It probably will ony show up with lots of players, but ideally I'd like to have some data before pushing the linux version out.
We can arrange a large scale test, but it will take some time. It would be great to get Tobba on board, who has access to all the goons.
May be totally unrelated but I was doing something similiar to this to simulate a floating effect:
Fx()
animate(src,pixel_y=16,time=30)
sleep(30)
animate(src,pixel_y=0,time=30)
.()


I believe this also caused Dream Seeker/Daemon to crash.
The game's server would run for upwards of 2-3 hours then suddenly freeze up with what seemed like memory issues.

I removed the above proc and am testing again. So far it's been running about two hours, I'll let it continue throughout the day and get back to you.

Btw as a matter of note, I only had 4 objects using this proc in the world at the time of the crashes.
You don't want to sleep when queuing up animate() effects, because you can't ensure that the animation context hasn't changed during the sleep().
Page: 1 2 3