IRC channel logs


back to list of logs

***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?
<wingo>thank you sneek
<wingo>sneek: botsnack
<ivladak> /msg NickServ identify
<amz3>héllo :)
<amz3>let's experiment with building a simple chatbot
***Zachte-g is now known as God_hates_lags
<paroneayea>my favorite part about is the rotating gif.
<paroneayea>cool that it uses a JIT compiler tho
<dsmith-work>Happy Friday, Guilers!!
<dsmith-work>sneek: botsnack
<OrangeShark>happy friday to you too dsmith-work
<paroneayea> "dicitonary of algorithms and data structures"
<paroneayea>seems like a good thing to have bookmarked
<OrangeShark>hi amz3
***holomorp1 is now known as holomorph
<amz3>framagit suppport static pages \\o/
<wingo>evening :)
<dsmith-work>Hey hey!
<wingo>ACTION thinks of doing in guile
<davexunit>lol at WTF::Lock
<davexunit>wingo: lightweight locks sound like a great idea
<davexunit>ACTION experiments in nonblocking i/o for keyboard/mouse/joystick events
<random-nick>how do they implement the waiting?
<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?
<davexunit>if I read correctly...
<wingo>well the goal is better fast paths
<davexunit>area of relative ignorance for me
<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>not one queue per mutex
<davexunit>sounds like a nice improvement
<random-nick>but is this faster than just using pure futexes?
<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>via an async interrupt
<wingo>right now we effectively implement our own mutexes, more or less
<wingo>that's our "fat mutexes"
<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>oh, I see
<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>it will all fold
<wingo>makes me envious of c++, which is a weird feeling :)
<random-nick>but the implementation in webkit is not really important for guile
<random-nick>can GCC fold that?
<wingo>in c++, yes
<wingo>in c with enough "static inline" yes also
<random-nick>is that why sqlite3 puts everything in one file?
<random-nick>so it can be folded
<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
<random-nick>gcc even has a flag for that, -fwhole-program
<random-nick>which tells gcc the file is the whole program
<wingo> is the missing piece from that webkit article
<wingo>anyway, zzz
<wingo>night :)