Time |
Nick |
Message |
00:06 |
|
natewrench joined #minetest-dev |
00:15 |
|
proller joined #minetest-dev |
00:50 |
|
YuGiOhJCJ joined #minetest-dev |
03:00 |
Baytuch |
Good morning, sfan5. My game is missing in the server list. |
03:02 |
|
proller joined #minetest-dev |
03:03 |
Baytuch |
Can you check please to request from 198.251.89.91 to serverlist service? |
03:48 |
|
proller joined #minetest-dev |
04:00 |
|
MTDiscord joined #minetest-dev |
04:03 |
|
fluxionary joined #minetest-dev |
04:56 |
MTDiscord |
<savilli> Baytuch: You can check requests to servers.minetest.net from your side by yourself. It can help to diagnose the issue. |
05:04 |
|
fluxionary joined #minetest-dev |
05:51 |
|
appguru joined #minetest-dev |
06:01 |
|
tekakutli joined #minetest-dev |
06:29 |
MTDiscord |
<jordan4ibanez> Fleet? like the IDE? |
06:40 |
pgimeno |
sfan5: two threads can't concurrently update the same Lua state, but they can still concurrently run - for example one can be running a function while the other is updating the state, or both can be running functions at the same time. Since the Lua state gets locked on every access by each thread, the resulting performance is horrible, especially if both threads need to access the state at the same time, as it can't be simultaneous. That's how |
06:40 |
pgimeno |
multithreaded CPython works (or worked - haven't looked lately). In fact I believe that's how the multithreaded mapgen worked in past in Minetest. |
06:41 |
pgimeno |
https://wiki.python.org/moin/GlobalInterpreterLock |
06:44 |
pgimeno |
love2d, by contrast, uses separate Lua environments and instead has an implementation of communication channels to share data between threads - basically a serializer and deserializer, and in fact the data sharing is fairly limited (it was limited to unnested tables until just recently). |
06:47 |
pgimeno |
What threads can freely share, however, is love2d objects: images, fonts, meshes, etc. There's a special one called "data" created with FFI in mind, that can be shared by multiple threads - but the user is responsible for locking. In fact the communication channels can serve as a locking mechanism, and there's a mutex implementation made using these channels, which use locking themselves. |
06:48 |
pgimeno |
https://github.com/slime73/love-mutex |
06:49 |
pgimeno |
I believe that the love2d way is the correct one, and if I've understood correctly, that's the approach taken by the new multithreaded Lua code, which is awesome. |
06:49 |
pgimeno |
I'm not sure if there's an equivalent to the love2d channels in minetest, though. |
06:50 |
pgimeno |
https://love2d.org/wiki/Channel |
06:50 |
|
appguru joined #minetest-dev |
06:57 |
pgimeno |
love2d has done (much to the frustration of many people) what minetest tries to largely avoid: break the API in about every major version. It's a real PITA, but the end result is that said API is quite polished and there may be lessons to learn from it. |
06:59 |
|
calcul0n joined #minetest-dev |
07:04 |
Baytuch |
processRequest -> RT_FETCH |
07:05 |
Baytuch |
CURLE_OK |
08:53 |
Baytuch |
Oh.. I forget about 'curl_verify_cert' option on the my current config. |
08:53 |
Baytuch |
and set to true now |
08:54 |
|
srifqi joined #minetest-dev |
08:55 |
srifqi |
hello. merging #13617 in around 5 minutes |
08:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/13617 -- Use absolute URL for the roadmap by numberZero |
09:00 |
srifqi |
done |
09:07 |
|
appguru joined #minetest-dev |
10:00 |
|
Baytuch left #minetest-dev |
10:16 |
|
diceLibrarian joined #minetest-dev |
10:31 |
|
diceLibrarian joined #minetest-dev |
11:31 |
|
proller joined #minetest-dev |
11:44 |
|
qur joined #minetest-dev |
12:34 |
|
appguru joined #minetest-dev |
13:00 |
|
Desour joined #minetest-dev |
13:05 |
Desour |
pgimeno: AFAIK multithreading within one lua state isn't implemented in luajit nor puc lua though. adding channels for communication doesn't need heavy modifications in the interpreter |
13:06 |
|
proller joined #minetest-dev |
13:10 |
Desour |
btw. for userdata that references shared data, we can't put the responsibility of locking to the user (unless race-conditions can't result in unwanted or undefined state), as our lua env is sandboxed |
13:11 |
pgimeno |
yeah, love2d's security requirements are different to minetest's |
13:12 |
pgimeno |
and I have to look up the locking part to show what I mean |
13:14 |
Desour |
it would be nice if a reference could be either shared immutably or be mutable by one thread and only accessible by this thread |
13:23 |
pgimeno |
https://github.com/minetest/minetest/blob/0.4.17.1/lib/lua/src/llimits.h#L109 |
13:23 |
pgimeno |
right now I'm not sure if it applies to LuaJIT as well as PUC Lua |
13:23 |
pgimeno |
I went to 0.4.17 because I was sure I found it in the source for that |
13:24 |
pgimeno |
PUC Lua is full of lua_lock()/lua_unlock() calls all around |
13:27 |
pgimeno |
I believe that with appropriate lua_lock definitions, Lua can be made multithreaded by using a GIL |
13:28 |
pgimeno |
it seems I misremembered when I thought that the Lua mapgen used a shared environment |
13:29 |
pgimeno |
anyway, GILs suck so everything's OK as is |
13:29 |
Desour |
interesting! |
13:57 |
sfan5 |
no idea about luajit but puc lua optionally supports a GIL as you already found out |
14:03 |
Desour |
see also: http://lua-users.org/wiki/ThreadsTutorial |
14:45 |
|
pgimeno joined #minetest-dev |
14:59 |
|
localhost[m]1 joined #minetest-dev |
15:02 |
sfan5 |
having channels for communication between threads in MT would be nice but it doesn't really fit right now |
15:02 |
sfan5 |
we don't have threads that are freely created |
15:03 |
sfan5 |
all of them are fixed purpose and you can't just go and block them to wait for some message in a channel to arrive |
15:07 |
sfan5 |
#13618 ready for review with some early changes |
15:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/13618 -- [NOSQUASH] Script api fixes and preparations for `mglua` by sfan5 |
15:39 |
|
pmp-p joined #minetest-dev |
16:01 |
|
Wuzzy joined #minetest-dev |
18:01 |
|
pmp-p joined #minetest-dev |
18:11 |
|
LandarVargan joined #minetest-dev |
18:22 |
|
mokmokfish[m] joined #minetest-dev |
18:33 |
|
diceLibrarian joined #minetest-dev |
18:43 |
|
appguru joined #minetest-dev |
19:27 |
|
appguru joined #minetest-dev |
19:31 |
|
ShadowNinja joined #minetest-dev |
19:40 |
|
Desour joined #minetest-dev |
20:47 |
|
diceLibrarian joined #minetest-dev |
21:36 |
|
appguru joined #minetest-dev |
21:53 |
|
Desour joined #minetest-dev |
22:32 |
|
panwolfram joined #minetest-dev |
22:33 |
|
natewrench joined #minetest-dev |
22:59 |
|
nrz_ joined #minetest-dev |
23:16 |
|
izzyb joined #minetest-dev |
23:29 |
|
natewrench joined #minetest-dev |
23:38 |
|
proller joined #minetest-dev |