Minetest logo

IRC log for #minetest-dev, 2015-04-05

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:21 paramat i'll push this trivial fix later game#485
00:21 ShadowBot https://github.com/minetes​t/minetest_game/issues/485 -- Default/mapgen: Fix missing num_spawn_by = 1 line for papyrus by paramat
00:27 est31 joined #minetest-dev
00:28 est31 paramat, I think game#485 is small enough to be merged directly.
00:28 ShadowBot https://github.com/minetes​t/minetest_game/issues/485 -- Default/mapgen: Fix missing num_spawn_by = 1 line for papyrus by paramat
00:29 paramat yes i was going to merge it without approval =)
00:30 paramat the ice PR can wait for the mtg team to see it on sunday
00:35 paramat now pushing game#485
00:35 ShadowBot https://github.com/minetes​t/minetest_game/issues/485 -- Default/mapgen: Fix missing num_spawn_by = 1 line for papyrus by paramat
00:38 paramat done
00:54 paramat left #minetest-dev
01:02 Wayward_One joined #minetest-dev
01:15 Taoki joined #minetest-dev
02:04 roniz joined #minetest-dev
02:17 est31 Merging in 5 minutes: http://pastie.org/10074257
02:26 hmmmm looks good to me
02:27 kahrl that was more than 5 minutes later :P
02:28 est31 now its pushed
02:30 ShadowNinja est31: Don't remove newlines at the ends of files.
02:31 ShadowNinja Also, should be 115 mins IIRC.
02:31 ShadowNinja 15 rather.
02:31 est31 ShadowNinja, why?
02:31 ShadowNinja est31: Because they're supposed to be there.
02:31 est31 why that?
02:33 ShadowNinja est31: Lets you can them together, start editing at the end easily, some tools require it.
02:33 ShadowNinja It could be changed if there are good reasons though.
02:33 ShadowNinja est31: Have you read all of http://dev.minetest.net/All_r​ules_regarding_to_development ?
02:33 est31 ok, noted.
02:35 est31 ShadowNinja, I think I have read most, but I guess reading it all again is a good idea
02:38 Miner_48er joined #minetest-dev
02:39 kahrl huh, why was the "rule 1" stuff removed from http://dev.minetest.net/Git_Guidelines?
02:39 hmmmm who wrote all this stuff
02:39 hmmmm i didn't even know those pages existed
02:40 est31 This isn't done at all: http://dev.minetest.net/Merging​_core_pull_requests_to_upstream
02:50 misprint joined #minetest-dev
03:05 est31 #2602 looks good except of style issues and it needs to be squashed. they use a map now instead of a vector. What do you think, can I merge it when I squash and fix the style?
03:05 ShadowBot https://github.com/minetest/minetest/issues/2602 -- move particle spawners to env by obneq
03:05 * est31 needs a second +1.
03:06 hmmmm hopefully those are going to get squashed...
03:06 misprint joined #minetest-dev
03:07 hmmmm est31, are you sure that pull request is ready?
03:07 VanessaE est31: wait a bit - jin_xi has more stuff he's doing
03:07 hmmmm yes, please don't be so ready to merge PRs unless there's been actual discussion
03:08 VanessaE #2587 in particular
03:08 ShadowBot https://github.com/minetest/minetest/issues/2587 -- wip irrlicht particles 2 by obneq
03:08 est31 I have seen that one
03:09 est31 its only a "move A out of server.cpp" PR, nothing functional
03:09 est31 (read it in one of those wiki rules that server.cpp has to be shortened.)
03:10 est31 I'll let jin_xi do it themselves
04:04 est31 joined #minetest-dev
04:27 hmmmm agh
04:27 hmmmm i never tried compiling with leveldb before, but now that I am, I get an error
04:27 hmmmm precisely because I'm using gcc
04:27 hmmmm compile with clang, no problem
04:27 hmmmm but at the same time i have no debugging info
04:39 ShadowNinja I am now a l33t net pro ;-) #2604
04:39 ShadowBot https://github.com/minetest/minetest/issues/2604 -- Add support for multiple listen addesses by ShadowNinja
04:52 est31 my craft speedup patch #2596 works with deadbeef power
04:52 ShadowBot https://github.com/minetest/minetest/issues/2596 -- Crafting speedup by est31
04:52 est31 did you know that 0xdeadbeef allocates exactly 32 bytes?
04:59 ShadowNinja est31: Um, you mean (void* (*)(void))(0xdeadbeef)()?  (call that address as a function returning a void*).
05:00 est31 you know, dead beef is so salty, so that I can use it for salting...
05:00 ShadowNinja est31: Or you mean it's 32 bits because it's a 8-char hex string?
05:02 ShadowNinja est31: It looks like you're basically just making a custom std::unordered_map.
05:02 est31 yes that one. 8 characters times 4 bits per character are 32 bit
05:02 est31 mhh
05:02 est31 dammit I have 32 bit free space
05:02 est31 byte
05:02 est31 we have to live with the zeroes
05:03 est31 we don't want to use too much salt do we
05:05 ShadowNinja est31: Why do you need a salt?
05:05 est31 bc I'm hashing.
05:05 est31 would live well with 0 too I guess
05:06 est31 but as the method requires a salt to be passed...
05:06 ShadowNinja est31: This kind of change should come with a lot of comments, or someone is going to go "why all this complexity?"
05:06 est31 see commit message
05:07 ShadowNinja est31: The code should be understandable without reading through the commit history for the commit that added the code.
05:08 ShadowNinja The commit message should only describe what the commit does, not what the code does.
05:10 est31 ShadowNinja, I can move paragraphs 2, 3 and 4 into comments somewhere in the code, is that sufficient?
05:11 ShadowNinja est31: Add comments anywhere that might be confusing.
05:11 est31 lol
05:11 ShadowNinja I read the commit message but I still don't understand what it does, except that it apparently involved three hashtables.
05:12 ShadowNinja Maybe I'm just tired though.
05:12 est31 you made #2604 thats alot of work
05:12 ShadowBot https://github.com/minetest/minetest/issues/2604 -- Add support for multiple listen addesses by ShadowNinja
05:12 hmmmm jesus christ
05:13 hmmmm well that's not overkill or anything
05:13 est31 hmmmm,  my change or ShadowNinja's?
05:13 hmmmm yours :p
05:14 est31 you want to have the server to spend the quarter of a second searching for sth to craft?
05:14 hmmmm no, but that's a false dichotomy
05:14 hmmmm you could've gained roughly the same speed increase just using std::map
05:16 hmmmm i don't quite understand the whole "layers" thing
05:16 hmmmm ahh I see what you did
05:17 est31 craft definitions with groups in their grid are a problem otherwise
05:17 hmmmm hrmm
05:17 hmmmm what is the hash output size of xxhash?
05:17 est31 32 bytes
05:17 hmmmm yikes
05:17 est31 (u32)
05:17 hmmmm erm, u32 is 32 bits
05:18 hmmmm 32 bytes would be something like SHA-2
05:18 est31 ok
05:18 hmmmm that's a lot of stuff going on just for 4 bytes of hashing
05:19 hmmmm unless the collision properties are superior to that of a 64-bit murmur hash, why not just use that one instead?
05:19 est31 I'm ok with other algs too, just want to have 4 bytes at the end
05:19 hmmmm 1). murmur hash is already there
05:19 hmmmm 2). it has twice as big of a space
05:19 hmmmm hash space
05:19 hmmmm 3). it doesn't need to be "initialized"
05:19 est31 ?
05:19 hmmmm but maybe this is better, i need to understand the layers better
05:20 est31 ah initialisation is still needed
05:20 est31 its because we allow aliasses to be defined after craft definition
05:20 est31 otherwise we would need to change even minetest_game
05:21 hmmmm hmm
05:21 hmmmm in the header file it actually compares against murmur hash
05:21 hmmmm this appears to be twice as fast
05:21 hmmmm key word appears :p
05:21 est31 or not, because we dont use aliases there in craft definitions, but what I have checked is that the files get loaded in the wrong order
05:21 hmmmm i'd just prefer to not have unnecessary stuff
05:22 hmmmm and like this is a whole huge new file
05:23 est31 murmur seems to be ok too.
05:25 est31 I'll let it do murmur
05:25 hmmmm you don't have to change things if this works fine
05:25 hmmmm the work has already been done
05:26 * hmmmm scratches head
05:26 est31 its a single line commit for the usage, and a texteditor u32->u64 replace
05:26 hmmmm okay, so tell me if this is how it works:
05:26 hmmmm different *parts* of the CraftDefinition get hashed based on something
05:27 hmmmm each "level" controls how much of the definition is hashed
05:27 hmmmm yes or no so far?
05:27 nore joined #minetest-dev
05:27 est31 tough descision
05:27 est31 the deeper the "level" the more the collision rate
05:28 est31 so yes to that one
05:28 est31 and yes to the first
05:28 hmmmm but wait that doesn't make sense
05:28 hmmmm if you have more data being hashed, wouldn't that lower the collision rate?
05:29 hmmmm actually nevermind, that's true for things below the hash size
05:29 est31 for me the highest level is the one thats checked first, the CRAFT_HASH_TYPE_ITEM_NAMES
05:29 hmmmm how likely is it that there's a collision to begin with?
05:30 est31 at that layer you can collide if you have two reorderings of the same craft grid
05:30 hmmmm and so what if there is a collision?  shouldn't you have a collision resolution mechanism already?
05:30 est31 yes
05:30 est31 there is one
05:30 hmmmm what is it?
05:30 est31 the map maps to a vector
05:30 est31 (from the hash)
05:31 hmmmm can't you just use a multimap?
05:31 * est31 googles
05:31 hmmmm std::multimap
05:31 est31 is it stable?
05:32 hmmmm in which sense?
05:32 hmmmm like a stable sort?
05:32 est31 yes
05:32 hmmmm why do things need to be sorted?
05:32 est31 so when I enter two elements with the same key in a certain order, do I also get them with that order
05:33 est31 its so that later craft definitions can override earlier ones
05:33 est31 some mods do that
05:33 hmmmm the answer is that i don't know
05:33 * est31 reads doc
05:34 hmmmm i *would* assume it uses std::sort internally but i have no way of knowing that for sure
05:35 est31 it seems its not stable http://bytes.com/topic/c/answe​rs/480984-std-multimap-stable
05:35 est31 by standard
05:35 est31 but all implementations keep it stable
05:36 hmmmm ahh
05:36 hmmmm looks like you should stick with your map/vector implementation then
05:36 est31 yea
05:39 hmmmm so the levels are in this order:
05:40 hmmmm CRAFT_HASH_TYPE_COUNT, CRAFT_HASH_TYPE_ITEM_NAMES, then CRAFT_HASH_TYPE_UNHASHED as the lowest level
05:40 hmmmm correct?
05:40 est31 yes
05:40 est31 no
05:40 est31 no
05:40 est31 item names and count flipped
05:40 hmmmm okay :)
05:40 est31 like they are defined in the enum
05:41 hmmmm so a count of the items has more uniqueness than the names of the hash types?
05:41 hmmmm err, the name of the items
05:41 est31 no, read above
05:42 hmmmm yeah my questions still stands
05:42 hmmmm so why not make the hash just use *both* item names and count?
05:42 est31 count of the items has less uniqueness agreed
05:43 est31 the hash already does that internally, by adding the \n occurences into the result
05:43 est31 but thats not the point
05:43 est31 the point is that there are craft definitions where names dont help
05:44 est31 thats all craft defs where you have one element which is group:something
05:44 est31 then you can't add group:something to the hash
05:44 hmmmm ahhh
05:44 hmmmm ahhhhh
05:44 est31 you dont know to check that on the other side
05:44 hmmmm i just realized that a craft def lookup is actually sort of complicated
05:44 est31 you could make a brute force search
05:45 est31 horribly expensive
05:45 hmmmm by the way, if you don't specify a = number in an enum, it's 0 by default
05:45 hmmmm so starting an enum by ELEMENT_NAME_HERE = 0 is redundant
05:45 est31 nice
05:46 hmmmm looks good to me
05:46 hmmmm +1
05:46 hmmmm you *could* switch to murmur hash if you'd like
05:46 est31 yaay
05:46 hmmmm it's in util/numeric.h
05:46 est31 will switch to murmur
05:46 est31 yea found it
05:46 est31 and will remove the =0
05:46 hmmmm yea I added that for alphanumeric seeds
05:47 hmmmm i'm glad it's being useful somewhere else too
05:48 hmmmm ugh so it looks like i'm gonna have to disable leveldb for now
05:56 leat joined #minetest-dev
05:57 leat joined #minetest-dev
06:22 Megaf_ joined #minetest-dev
06:25 Hunterz joined #minetest-dev
06:31 hmmmm speaking of which I just found a bug with murmur_hash_64_ua()
06:31 hmmmm I wonder if the memcpy() call was there originally in the code I got it from or did I add that??
06:37 est31 github is stupid
06:37 est31 I've pushed to the branch, but nothing changed
06:38 est31 https://github.com/minetest/minetest/pull/2596
06:38 est31 here an old version of my commit is shown
06:38 est31 and on my branch, the new version is shown: https://github.com/est31/mi​netest/tree/craftingspeedup
06:39 est31 this is the new version https://github.com/est31/minetest/commit/​927c33309b06d0c1c96e87efc04eadfd055c0cc2
06:39 est31 the old version still has the xxhash thingy
06:41 est31 ShadowNinja, can you confirm that there are enough comments now?
06:52 leat joined #minetest-dev
07:03 leat joined #minetest-dev
07:07 selat joined #minetest-dev
07:11 est31 ShadowNinja is asleep as it seems
07:14 est31 I have however made the code document
07:15 est31 added some hints here and there
07:18 est31 idk should I wait for him?
07:23 est31 I think I'll merge, as I mostly did what he requested.
07:23 est31 pushing #2596 now
07:23 ShadowBot https://github.com/minetest/minetest/issues/2596 -- Crafting speedup by est31
07:41 jin_xi joined #minetest-dev
07:46 leat joined #minetest-dev
07:59 Krock joined #minetest-dev
08:08 kilbith joined #minetest-dev
08:13 err404 joined #minetest-dev
08:47 OldCoder joined #minetest-dev
09:07 leat joined #minetest-dev
09:15 nrzkt joined #minetest-dev
09:17 nrzkt hi, i pushed two changes: some uninitialized variabled into ConnectionEvent and also return 0 after assert in est31 craftdef code to make clang happy
09:58 leat joined #minetest-dev
10:14 cib0 joined #minetest-dev
10:26 leat joined #minetest-dev
10:30 leat joined #minetest-dev
10:36 lordfingle joined #minetest-dev
10:37 lordfingle hello
10:56 kilbith [Alert] nrzkt, 8804c47e still cause a crash near the signs_lib : http://pastie.org/10074694
10:57 kilbith it was fine before that commit
10:57 kilbith https://github.com/minetest/minetest/commi​t/8804c47e59b550ec9a533de662f086af623d68c1
10:59 nrzkt ugh. wtf we only catch an error without doing nothing else
10:59 nrzkt i think the problem was never solved in fact
11:00 kilbith it was fine before that commit (bis)
11:00 kilbith ie. no crash
11:00 nrzkt this commit does nothing
11:00 kilbith i have crashes with it, none before
11:02 nrzkt please retest without the commit it's impossible. This commit only add a catch for packet error on client side to catch PacketError when the packet is unreliable
11:02 nrzkt then the crash was also present before
11:03 kilbith factually, it is
11:03 kilbith i'm not talking about theory man
11:03 nrzkt also, please note the catching error is not in this function but in processActiveObjectMessage
11:03 selat joined #minetest-dev
11:03 nrzkt and processActiveObjectMessage hasn't changed. Then the problem was here before.
11:04 leat joined #minetest-dev
11:18 leat joined #minetest-dev
11:22 ElectronLibre joined #minetest-dev
11:38 nrzkt joined #minetest-dev
12:40 roniz joined #minetest-dev
13:04 chchjesus joined #minetest-dev
13:28 SopaXorzTaker joined #minetest-dev
13:46 cib0 joined #minetest-dev
13:46 est31 joined #minetest-dev
14:18 hmmmm joined #minetest-dev
14:37 est31 breaking the network with git versions of minetest that are newer than the latest release *is* allowed, isnt it?
14:38 est31 because I don't like to avoid breaking it when I want to change sth the protocol changed
14:38 est31 e.g. master has a new packet
14:38 est31 and I want to remove a flag
14:38 est31 from that packet
14:38 est31 then I dont want to make a new protocol version just because
14:39 est31 of course, compat with releases needs to be maintained
14:40 est31 hmmmm, ^
14:40 hmmmm man i'm trying to get minetest to compile
14:40 hmmmm and you're over there talking about protocol changes
14:43 est31 I just asked because nrzkt seemed to have other things in mind in a comment on a PR (not related to my example).
14:43 est31 and I had plans to change packets that were introduced in protocol version 25.
14:45 est31 to not make it overly complicated (having legacy logic for protocol versions that only clients/servers have that use a custom source build of un-released (as in release) minetest)
14:45 hmmmm if there are protocol changes within a version we try to coordinate and batch them all together
14:45 est31 ok
14:46 est31 I'm not sure what nrzkts auth plans are, my ideas require those packet changes.
14:47 est31 thanks for answering, I'm off now. the PR I mentioned was 2592 btw
14:47 hmmmm okay.
14:47 hmmmm pfth
14:48 hmmmm looks like I got a minimal test case for my issue
15:24 SopaXorzTaker joined #minetest-dev
15:45 leat joined #minetest-dev
15:58 leat joined #minetest-dev
16:07 MinetestForFun joined #minetest-dev
16:21 Megaf_ Man, I never get nrzkt online
16:54 cib0 joined #minetest-dev
17:06 MinetestForFun joined #minetest-dev
18:16 jin_xi joined #minetest-dev
18:18 rubenwardy joined #minetest-dev
18:29 paramat joined #minetest-dev
18:32 paramat nore, sfan5, please could you review/approve game#484 ? Since PilzAdam's comment i have added more screenshots showing why icesheet caves are so messy
18:32 ShadowBot https://github.com/minetes​t/minetest_game/issues/484 -- Default/nodes: Make ice not ground content by paramat
18:50 Calinou joined #minetest-dev
19:07 MinetestForFun joined #minetest-dev
19:07 MinetestForFun joined #minetest-dev
19:27 fz72 joined #minetest-dev
19:36 err404 joined #minetest-dev
20:42 ud1_ joined #minetest-dev
20:44 Taoki joined #minetest-dev
20:59 hmmmm do you guys think the currently executing mod name should be available after initialization?
21:22 Jordach joined #minetest-dev
21:38 paramat erm, can't think of a use for that at the moment
21:39 ElectronLibre left #minetest-dev
21:45 paramat because this is more of a mapgen issue i will probably go ahead and push game#484 soon, seems obvious to me there should not be caves in icesheet. highlighting hmmmm and sfan5
21:45 ShadowBot https://github.com/minetes​t/minetest_game/issues/484 -- Default/nodes: Make ice not ground content by paramat
21:47 sfan5 paramat: seems ok
21:51 paramat thanks, alternatively i could edit mgv6 caves to check for ice, this may be better i will think on it
21:54 est31 joined #minetest-dev
21:54 hmmmm paramat +2
21:54 paramat thanks
21:54 est31 hmmmm, this isn't possible: http://irc.minetest.ru/minet​est-dev/2015-04-05#i_4214025
21:55 est31 we have a common lua context after loading
21:55 est31 it is possible to e.g. use the stack, but that isn't nice either, imagine library mods.
21:55 hmmmm mods register callbacks on loading
21:55 est31 ?
21:56 hmmmm so you just register the name of the mod associated with the callback
21:56 hmmmm then every time it's called, set the context
21:57 est31 if we do it that way, the fact whether we register something for that special mod should be settable by flag
21:57 est31 but mh
21:58 est31 your solution works without that flag too
21:58 hmmmm the mod api is basically a miniature OS with cooperative multitasking
21:59 hmmmm setting the context before making a callback is akin to setting segment descriptors to point to the correct processes' PEB before handing over execution
22:01 est31 !g PEB process operating system
22:01 ShadowBot est31: https://msdn.microsoft.com/en-us/library​/windows/desktop/aa813706(v=vs.85).aspx | Indicates whether the specified process is currently being debugged. The PEB structure, however, is an internal operating-system structure whose layout may ...
22:01 paramat ah.. v5/v7 cavegen already check for ice (as well as checking 'is ground content') and don't remove it. v6 cavegen doesn't check for 'is ground content' or for ice, i will update it. so the simplest fastest solution is making ice not ground content .. will do this
22:01 est31 yeah
22:01 est31 (to hmmmm)
22:02 hmmmm that being said
22:02 hmmmm it would be very nice if we had more advanced scheduling constructs for modding
22:02 est31 is luajit multithreadable?
22:03 paramat (..perhaps better and simpler i can also make water and lava not ground content)
22:03 hmmmm multithreading is absolutely useless because of the scope of the locks held
22:04 hmmmm what would be nice is if mods could be pre-empted however
22:04 est31 yes
22:04 est31 then they dont cause lags
22:05 est31 or still do, but dont stop the whole server
22:06 paramat (..this will reduce checks for more speed, will do)
22:06 est31 problem is however: data can change
22:07 hmmmm yeah
22:07 hmmmm the solution to this would be to take a snapshot of the map or whatever it is at that point in time it's being called
22:07 hmmmm and each time the thread is resumed, it'd read the map out of that snapshot
22:07 hmmmm the problem is that old mods wouldn't be able to do this...
22:08 hmmmm so it'd break compatibility?
22:08 est31 even if, how do you feed back the changes?
22:08 hmmmm you have a transaction list
22:08 est31 this still would require certain locks
22:08 hmmmm yeah there's locking any way you look at it, but this modifies the scope of locks
22:09 est31 yea
22:09 est31 umm no
22:09 est31 your idea is to dynamically cache something, but that can end up bad
22:09 hmmmm how so?
22:09 hmmmm explain.
22:11 est31 what is when mod A does something on place X and adds them to the transaction log. then player B comes, modifies sth on place X and then mod C sees what A has done and adds something else to the transacion log too, overriding the players modifications.
22:12 hmmmm if another mod attempts to read a MapBlock that has a pending write transaction it should take the most recent version
22:13 hmmmm so it's like this:
22:13 est31 also, if we have this model implemented, nothing stops us from multithreading, does it?
22:13 hmmmm mod A expresses its intent to read an area of nodes from (4, 3, 10) to (20, 19, 26)
22:14 hmmmm so it atomically sets a little flag on each of them that means they're currently being read
22:15 hmmmm then if another mod comes around to write on any one of those, it notices the flag and it instead adds a pending transaction to that
22:15 hmmmm this is kind of like the idea behind RCU
22:16 est31 you basically want to implement area-based locking?
22:16 hmmmm it's not area-based locking because there are never any waiters
22:17 hmmmm the only time a lock does happen, it's to do something with the transaction list, which is very well defined and bounded
22:17 hmmmm so we know the lock operation will take at the very most, say, 1 ms
22:17 hmmmm and yes, this would allow for multithreading
22:19 hmmmm but let's think about the broader problem than ways to efficiently lock the map structure
22:19 hmmmm what is it we're actually trying to accomplish?
22:19 est31 when both mod A and B add transactions, mod A places dirt, mod B places stone.
22:19 hmmmm access to the environment needs to be synchronized because __________________________________ ?
22:20 est31 mod A starts from (3,0,0), B starts from (0,0,0)
22:20 est31 and both work in opposite directions
22:20 hmmmm note this would only work if the mods define the bounds in which they intend to operate
22:21 hmmmm if they attempt to access a piece of the map that hasn't been snapshotted, it'll have to incur a penalty
22:21 est31 we can get in the log: (A, dirt (3,0,0,)), (b, stone, (0,0,0)), (A, dirt (2,0,0,)), (B, stone (1,0,0,)), (A, dirt (1,0,0,)), (B, stone (2,0,0,)), (A, dirt (1,0,0,)), (B, stone (3,0,0,)), (A, dirt (0,0,0,))
22:22 hmmmm that's not an issue.
22:22 est31 then in the end, we have (stone, 3,0,0) (stone, 2,0,0) (dirt, 1,0,0) (dirt 1,0,0)
22:22 hmmmm er
22:23 est31 basically and config possible, depending on scheduling
22:24 hmmmm by definition, mod B is taking a snapshot of the current state of the map
22:25 hmmmm perhaps there could be a R/W flag
22:25 hmmmm if one mod takes an R/W snapshot of a mapblock, then another mod later on can be notified of this
22:26 hmmmm "hey there's another mod that intends to modify this area of map, so you might not be looking at the most recent"
22:26 est31 so we allow the mod to either wait, or not wait
22:26 hmmmm at this point it could say it's either OKAY with that
22:27 hmmmm or it's not okay, and it wants a callback when that mod has no pending writers that came before it
22:28 est31 that sounds better
22:28 est31 mods who intend to write should also have this option: is there currently any mod reading that block?
22:28 hmmmm but, in practice, all mods are going to want the most up-to-date version, even when they won't really need it
22:29 hmmmm so there's this
22:29 est31 its locking, again, btw
22:29 paramat left #minetest-dev
22:29 est31 not that I'd think its bad
22:30 est31 (locking with the option, nah I ignore)
22:30 hmmmm how about having a reader/writer lock
22:30 hmmmm multi-reader/single writer
22:31 hmmmm hrmm  http://en.wikipedia.org/wiki/Seqlock
22:33 hmmmm that's conceptually simpler but probably less useful
22:34 hmmmm as far as I can tell, the only reason why there currently needs to be an envlock is contention between serverthread and emergethreads
22:35 est31 seems so
22:35 hmmmm if emergethread sticks to creating only new blocks (i.e. we stop doing shenaningans in others pieces of the map outside of chunk boundaries) then in theory it wouldn't need synchronization
22:36 est31 if the data structures dont need it, yes
22:36 hmmmm the data structures can be made wait-free
22:36 est31 ?
22:37 est31 ah
22:37 hmmmm before the ServerThread enqueues mapblocks for emerging, it could reserve the nodes or whatever in the std::map//std::vectors
22:37 hmmmm and set it to NULL
22:37 hmmmm it'd also pass pointers to these newly created nodes in the data structures as part of the block-making data
22:38 hmmmm then when the emergethread is completely finished with making the blocks and initializing them, it'll atomically swap in the mapblock pointers
22:38 est31 what is this exactly supposed to do?
22:38 hmmmm it's just an idea
22:38 hmmmm it would become a useless idea if true mod multithreading were added
22:39 hmmmm i'm just saying that an envlock isn't strictly 100% necessary
22:39 est31 yes
22:39 est31 I dont know though how hard current envlock is
22:43 est31 As a first step on the multithread route, we can do it like freeminer, and move basic server tasks out of the thread that does the mods.
22:44 est31 so e.g. chat or moving SAOs aroung will still work, even when the server is busy doing other things
22:44 est31 around*
23:18 chchjesus joined #minetest-dev
23:38 hmmmm sure
23:38 hmmmm we should continue this discussion on the dev mailing list, don't you think?
23:38 est31 good idea
23:38 VanessaE we have a mailing list? :P
23:39 est31 http://lists.minetest.net/archives/​minetest-dev/2015-April/thread.html
23:39 est31 very testy
23:44 est31 ShadowNinja still hasnt said why my provider is greylisted
23:44 est31 also idk what that even means
23:44 VanessaE it means your provider is thought to be a source of spam.
23:45 est31 whatever, I didnt have to give them my mobile phone number
23:45 est31 which is good
23:45 VanessaE didn't say it was such a source :)  just that that's what I got when I looked it up yesterday
23:46 VanessaE (looked up "greylist" that is)
23:49 est31 btw, what happened of that nice ascii art network protocol comment?
23:49 est31 did it get deleted?
23:50 VanessaE ?
23:50 VanessaE on the list?  I see only one post at the moment.
23:50 est31 somewhere in network src, there was an ascii art
23:50 VanessaE oh
23:51 hmmmm you know
23:51 hmmmm I seriously wonder how much contention the envlock really has
23:51 hmmmm locks aren't slow, contention in locks is
23:55 VanessaE looks like it was removed, est31.  I don't find it anyway from a quick skim of the network code
23:55 VanessaE (unless it's just so small I missed it)
23:56 est31 nono was bit larger
23:56 est31 I guess nrzkt didnt want to maintain it
23:57 VanessaE est31: then I guess it's gone.  good luck finding the commit that nuked it though
23:57 est31 even if if it isnt maintained, its of no use
23:58 hmmmm so right now the client message model is that the game loop grabs events from multiple sources, e.g. network and environment
23:59 hmmmm we know this /works/, but does this make sense?
23:59 hmmmm shouldn't the game loop maintain a thread-safe message loop that it exposes to event producers, such as the environment and network?
23:59 VanessaE hmmmm: sure, it makes perfect sense, if we can guarantee that no one event will ever take longer to process than the minimum amount of time that it'll take for another event to arrive

| Channels | #minetest-dev index | Today | | Google Search | Plaintext