***heroux_ is now known as heroux
***moby_ is now known as regain
<wingo>sneek: later tell civodul re _IO* deprecation -- the new names are better and they correspond to r6rs. what advantage does staying with the current names have? <amz3>let's experiment with building a simple chatbot ***Zachte-g is now known as God_hates_lags
***holomorp1 is now known as holomorph
<amz3>framagit suppport static pages \\o/ <davexunit>wingo: lightweight locks sound like a great idea <davexunit>ACTION experiments in nonblocking i/o for keyboard/mouse/joystick events <wingo>for wtf::lock? i believe they defer to the os <wingo>thread-specific wait mutex and cond or something <wingo>i.e. system facilities at that point <davexunit>but wtf::lock removes the use of certain other system facilities? <wingo>well the goal is better fast paths <wingo>once you've deemed that you need to suspend and wait, using the system is fine <wingo>also you can have just one system mutex/cond per thread <wingo>it's very close to futexes fwiw <random-nick>(afaik futex-based locks must at least be a whole int) <wingo>the problem i have is that i need to be able to do lock-mutex <wingo>but also be able to asynchronously signal that thread to wake up and possibly throw an exception or something <wingo>right now we effectively implement our own mutexes, more or less <wingo>whereas if i could manage the set of threads centrally and ask one to wake up and run an async, that would be nice <wingo>i should really just avoid touching this code <wingo>but i want us to stop using pthread_cancel so i need to find the minimal path to that also ;) <random-nick>will this have to rely on system facilities too? (would it suspend C code too or only suspend the VM) <wingo>ultimately waiting has to rely on the system, whether via pipe+select or pthread_cond_wait or something... <wingo>yeah talking about suspending the kernel thread, so system needs to be involved <random-nick>also WTF::Condition doesn't seem to implement a feature of pthread_cond_t: unlocking a locked mutex before sleeping <random-nick>I always found it confusing that you require a mutex <wingo>afaiu it does implement that feature <random-nick>implementing wait with "waitUntil(lock, Clock::time_point::max());" seems like a waste <random-nick>as far as I understand C++ this is all inline code anyway <wingo>yeah since it's inline i don't think it matters <wingo>makes me envious of c++, which is a weird feeling :) <random-nick>but the implementation in webkit is not really important for guile <wingo>in c with enough "static inline" yes also <wingo>i didn't know they did that but it certainly helps, the more you compile at one time, the more the compiler can do