***karswell` is now known as karswell
<CustosLimen>so the issue is that fat_mutex_lock works while a thread is still inside fat_mutex_unlock <CustosLimen>is your expectation that pthread mutex is recursive by default ? <CustosLimen>if EINTR is returned there a thread could stay inside fat_mutex_unlock and another thread can enter fat_mutex_lock <CustosLimen>and as a consequence the thread that got EINTR could override values that new thread that got into fat_mutex_lock set <CustosLimen>and in general actually this is just bad - that is just one example of how its bad <civodul>CustosLimen: could you send this explanation to bug-guile@gnu.org? <civodul>it would be ideal also if you could come up with a synthetic test that reproduces the error <CustosLimen>civodul, yeah - well I'm actually just first trying to figure out ow to fix <CustosLimen>civodul, I have one - but it only causes error on solaris <civodul>i guess no test can reproduce it with 100% certainty <civodul>but we can write it in a way to maximize the chances of reproducing it <CustosLimen>I think linux has some additional guaruntees on threading that makes this not happen <civodul>like have a thread that takes mutexes in a loop, and another one that sends SIGINT <civodul>dunno, that seems like a very generic kind of problem no? <CustosLimen>civodul, that EINTR is a recycled errno value - does not really mean what it normally means <CustosLimen>I'm going to see if I cant maybe fix this before posting to queue <CustosLimen>I'm actually not sure if the logic there is entirely sensible <CustosLimen>so EINTR means "EINTR when it has been interrupted by the delivery of a system async" <CustosLimen>basically I think this does not happen on linux cos linux has less spurious wakeups <CustosLimen>but I think this will happen every time you get a spurious wakeup <civodul>CustosLimen: could you post your thoughts to bug-guile@gnu.org? <CustosLimen>if only I could force a spurious wakeup from pthread_cond_wait <daviid>amz3: how are things wrt Guile-Gnome, Guile-Clutter install/packaging? you did see the 2 new releases I guess... <amz3>I saw them, I'm trying to setup properly my env <daviid>anything ask me ok? I updated Guile-Clutter's web-pages with a step that was missing for cogl install... <amz3>my system is broken somehow, now I can not compile guile stuff... I'm looking for a way around re-installing <daviid>amz3: ah! guix --rollback-to 'the-working-one <daviid>amz3: how/why did it brake? what distro are you on? <amz3>daviid: some kind of debian... I wish I could live without it really <daviid>amz3: I'm on debian too, till guix/guixsd has gnome-shell... <civodul>daviid: you could have Guix on top of Debian in the meantime <daviid>civodul: yes! it's the plan, I hope I can try it but now I'm so overloaded.. <daviid>and then, i'm afraid to fall i love with guix, abandonned all other project and become a guix hacker :) <amz3>btw daviid I think my graph explorer program I wanted to do in clutter is not interesting <amz3>I mean, I have no use of it ***dsmith-w` is now known as dsmith-work
<daviid>amz3: it is when you will play with guile-clutter that ideas will come ... <daviid>amz3: I recommend to compile tha all suite using stable, because Grip-Clutter extensively uses goops and a specific setting that only works using stable [there is a bug in master], and Grip-Clutter's examples rocks and will get you up and running 10 times faster then on your own ... <amz3>seems like installing guile-2.2 in /usr busted my box <daviid>amz3: anyway, let me know if/when you need help, I'll be very happy to try to set you up with Guile-Gnome and Guile-Clutter <amz3>ACTION back and running g-wrap install <daviid>amz3: I install master in /opt2 [not even /opt] so I can even rm -rf if needed ... then I wrote a script that sets env if I want to play with master ... <amz3>I should have used guix but anyway too late <daviid>did you clone g-wrap or using the tarball? <daviid>ok, you _must_ grab guile-cairo source code <daviid>amz3: it's fine, I was curious. but I would would clone the others <daviid>g-wrap is very stable, it won't change, probably, but the others will so cloning is a better idea imo <daviid>g-wrap compiles in less then a min, how did it go? <amz3>oops, missing gdk headers <amz3>btw I discovered a cross platform scheme implement of GI <daviid>amz3: I have some difficulties to follow you :) we wre on g-wrap then you say clutter, then this misssing gdk... which means you d'ont have a proper guile-gnome ... how about doing things step by step together? <amz3>yes I did step by step, because I go fast :) <daviid>so can you run an exaple in guile-gnome examples? <amz3>I compiled guile-gnome without gdk, because I did have gdk headers, but now it's ok <daviid>so guile-gnome is working then. try an example <daviid>in gtk/examples; chmod a+x hello.scm; ./hello.scm <daviid>cool! which version of cogl and clutter are you trying to cmpile? <daviid>try to fully respect the steps described ... it will be fine <amz3>libclutter 1.22.4-1build1 <daviid>yes, leaves this alone, gnome needs, but we can't <daviid>follow the steps described, all I can tell you is this <daviid>if you fail, then my description is not good, but i think it is <daviid>you have to really be precise though, all steps are eqully important, anyrthing else will fail <amz3>the configure let me through :) <daviid>Guile-Clutter is a racing car, a tiny little mistake and it's the accident :) <amz3>no, guile-clutter configure <daviid>so you now have cogl-1.12 and clutter 1.12 in /opt or somewhere? <amz3>you are right, I did not see that <amz3>I did not scroll that far <daviid>amz3: I took much of my time to describe, fully, step by step, so that even a non very advanced user could install... following these steps, absolutely all steps, 1 by 1, you'll have Guile-Clutter working in half an hour at the very most... <amz3>I was assuming that the distro lib would be enough <amz3>anyway, I'm done with cogl steps <amz3>daviid: to compile 'clutter', one requires to have correct PKG_CONFIG_PATH, LD_LIBRARY_PATH <amz3>right now, in the steps, it's only advised to do so for guile-clutter <daviid>amz3: correct will add this step for clutter too thanks <amz3>ACTION running guile-clutter <amz3>ahme grip clutter example actually <sepi>How can I get the type of a value in guile? <sepi>or better even in scheme <jmd>WTF is "clutter" actually? Nobody has ever really explained it. <daviid>amz3: great! so the bouncer is running? <vanila>i think clutter is a GUI toolkit <vanila>so it gives buttons to click on, textboxes etc <daviid>amz3: that's reaaly cool! and the toolbar? it has fancy things to play with [see the user help grip of the toolbar...] <amz3>yes everyting works as expected <daviid>amz3: congrat! you are the 1st grip-clutter user! :) <daviid>in grip-clutter examples, there is a template for you to start to play with <amz3>jmd`: it's kind of like GTK but lower level, also it use opengl <davexunit>Clutter provides a "scene graph" programming interface, AFAIK <mark_weaver>the wikipedia page says "Often Clutter is seen analogous to GTK+ but this is inaccurate. Only Clutter together with Mx or Nbtk can match the extent of the GTK+. This is also the reason why Clutter is used together with GTK+." <daviid>it is precisly not GTK like :) you should read the clutter wiki and the clutter bolg ... <davexunit>I personally don't know what one would use clutter for <amz3>yes, it's not gtk but the purpose of explaining... <amz3>"it's lower level compared to gtk" is correct? <amz3>maybe something like sly could be written on top of clutter <amz3>I read people use clutter to write games <amz3>it has many 2D operations readily available <amz3>jmd`: basically, I think I am accurate when I say it's 2D framework to build GUI application. <davexunit>using clutter for sly has been brought up before, but it's really not a good fit. the best fit is using OpenGL directly. <amz3>compared to GTK it doesn't have high level widgets, but the component to build them <amz3>You are probably right. I was thinking out loud that clutter provides GUI primitives but probably sly is better of raw opengl <davexunit>GUI primitives aren't very good for making games, especially 3d ones. <davexunit>the goals of the two projects are too different <amz3>Clutter must be faster that the reason to use clutter <amz3>But you have a point about 3D, IDK how clutter handles 3D <roelj>I used Clutter for a medical image viewer. But if I had to do it again I think we were better off using OpenGL directly.. <amz3>daviid: I can't find a list of event symbol like 'button-press-event <amz3>I'm trying to take control of the keyboard :) <daviid>amz3: till now I'm doing these the hacky way, patch welcome <daviid>wait button press? no these are ok, look for example in the code <daviid>it handles left right clicks ... in a proper design and programmed way I think, code review welcome of course ... <amz3>hmm, I may not need the keyboard <daviid>grip/clutter/examples/bouncer.scm line 93 ... <amz3>I'am asking about a list of signals, but I found what I was looking for in clutter doc <daviid>amz3: hum I actually build the clutter doc locally, so I can access without internet ... should I recommend that to maybe? <daviid>sure, but I think I should, and I now realize the web-pages miss an option I use, I actually use this locally, to compile clutter I mean: ./autogen.sh --prefix=/opt/clutter/1.xx --enable-deprecated=yes --enable-gtk-doc=yes [and sometimes even this --enable-debug=yes] ***jmd` is now known as jmd
<daviid>amz3: I have a working scroll actor example now, but it's not uploaded yes, will do asap <daviid>amz3: I've added the 2 above cited clutter [autogen] configure options to Guile-Clutter's web-pages now <amz3>I'm brainstorming how to proceed <CustosLimen>it worked on solaris actually but linux it keeps giving me "ERROR: In procedure fport_write: Bad address" <mark_weaver>CustosLimen: you need to ensure that guile ports are not accessed concurrently by multiple threads. <CustosLimen>mark_weaver, in c I can write to stderr from multiple threads - even though this might result in garbled output <mark_weaver>I suppose I should mention that there's a proposal to include built-in thread synchronization for all port operations in guile, and that I'm opposed to it because: (1) it would increase the cost of otherwise cheap operations like reading/writing a single byte by a large factor (e.g. ~10x on armhf), and (2) in order to avoid garbled output, you need to do thread synchronization yourself at a level in the code that understands the <mark_weaver>and whereas in C there are standardized *_unlocked variants, standard scheme has no such thing. <davexunit>fwiw, I'm opposed to built-in thread sync for ports, too. <civodul>problem is when a port is passed to third-party code that doesn't do appropriate locking <sneek>civodul, you have 1 message. <sneek>civodul, alezost says: about grub and dual boot: I don't really know, I didn't try the default GuixSD way of using grub because I don't like that it reinstalls grub after each system reconfiguring <civodul>as is the case with current-{output,error}-port <davexunit>wouldn't it be the responsibility of whoever is handling the port to do the necessary locking if they intend to use a multi-threaded design? <davexunit>I'm having a hard time seeing how something that seems like an uncommon thing to cause such a massive reduction in performance in the common case. <davexunit>I'd like to pay the price of thread synchronization only when my program benefits from threads. <civodul>the example i have in mind is 'guix pull', where we wanted to call 'compile-file' in parallel <civodul>so i agree with the rationale that mark & you describe, but it's muddier than this in practice ***dje is now known as xdje
<mark_weaver>one is that we could have multiple port objects with the same underlying file descriptor <mark_weaver>another is that we could arrange so that the worst that can happen when you access a port from multiple threads concurrently is for the output to be garbled <mark_weaver>that last one would require us to change the representation of the scm_t_port structure, which unfortunately is part of our public API <wingo>so what would you think about thread-specific port structures <wingo>like, a thread-local lookup for every time you interact with ports. not so nice i guess <wingo>civodul: instead of running the risk of multiple threads corrupting the port state, each thread could have its own port buffer and flush it when it likes <mark_weaver>yeah, that's one of the ideas that I thought of while trying to address your concerns <wingo>because there is synchronization happening in the kernel anyway <wingo>i totally get the concern that port-level locking doesn't have any semantic value; i just want no crashes :) <mark_weaver>thread-local lookups are very expensive on MIPS. I don't know how they are on arm <mark_weaver>so, my idea for that is to change scm_t_port to have a single pointer for each buffer (read/write/putback), and the buffer would be a substructure with the per-buffer fields. <wingo>the char-by-char case is really the one in which you want user-space buffering... <mark_weaver>so, for each buffer structure, its length and buffer address would never change. <mark_weaver>and the read buffer could be switched back and forth between the putback buffer and the real read buffer in a single pointer update <wingo>mark_weaver: an atomic pointer update, i would guess? <wingo>dunno what the atomic cost is on mips <wingo>if it would mean you have to do atomic reads to get the buffer <mark_weaver>well, I admit that I'm stretching the rules a bit, but I don't think it needs to be a special atomic operation in practice. <mark_weaver>atomic operations guarantee that all threads agree on the order of atomic operations, but we don't need that. <wingo>if you find a solution for which you can convince yourself that it's crash-free then i'm fine with it <wingo>we can back out all the port locking things <mark_weaver>so, the only problem is that scm_t_port is part of our API, so we'd have to change it obviously. <wingo>i'm not terribly concerned about that tbh <wingo>we can find ways to make the change not so bad <wingo>and people implementing ports are verrrrrrry few <wingo>people using port structures are probably more but still few <wingo>thank you for bearing with my paranoia! and apologies for stressing my poor solution rather than the problem :-) <wingo>and thanks of course for the hackings :) <mark_weaver>wingo: no need to apologize, your concerns were quite valid, and I'm glad we've found agreement :) <wingo>mark_weaver: in some alternate universe it would be nice to be able to expose the port buffers to scheme, to make it possible to, say, suspend a coroutine/delimited continuation when a port needs to block <wingo>i guess just have that idea in the back of your mind when hacking <wingo>if it fits in with what you're doing, anyway :) <davexunit>more support for non-blocking IO would be cool <amz3>It seemed to me that port were just fd wrappers <davexunit>pretty much every autotools-using project uses 'make check' to run tests <CustosLimen>tests are for noobs though so I never bothered to find that out ;) <CustosLimen>I think those two conditions should move out of the loop <CustosLimen>as this is causing mutex owner to be overwritten in case of spurious wakeup from pthread_cond_wait inside block_self <CustosLimen>cos it loops in that case and sets m->owner again but another thread could have already locked the mutex by then <CustosLimen>though I think that was accidently placed in the loop <CustosLimen>basically that `previous version` fat mutex unlock is from before it had the while(1) loop <CustosLimen>but I'm fairly sure that should just happen before the while (1) loop - and just want to know if someone has different views on this <mark_weaver>CustosLimen: can you send email to bug-guile@gnu.org with your analysis? <mark_weaver>sorry, can't talk about it now, and it would be good to have it in our bug tracker. <CustosLimen>thing is - the test case code I have works like clockwork to cause this on solaris <CustosLimen>but linux seems to not do spurious wakeups from pthread_cond_wait <mark_weaver>if you can't make it happen on linux, that's okay. we obviously want it to work on solaris as well.