Date: Tue, 28 Nov 2017 18:43:48 +0000 From: bugzilla-noreply@freebsd.org To: gnome@FreeBSD.org Subject: [Bug 199872] devel/glib20 Apps using glib 2.42.2 crashing with 'pthread_mutex_lock' abort Message-ID: <bug-199872-6497-NA4UtwPPz2@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-199872-6497@https.bugs.freebsd.org/bugzilla/> References: <bug-199872-6497@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D199872 --- Comment #21 from rozhuk.im@gmail.com --- (In reply to Guido Falsi from comment #20) > At present the glib20 port does not include an option to use inotify or y= our patch. Yes, and no one care this. But patches for both case available. > My patch is a simple incremental fix, which requires only importing upstr= eam bits. Small patch cant fix big ugly code. Why you do not remove/disable this code and use new kqueue or libinotify? > I'm not on the gnome team so I don't know which solution they will import= in > the tree, but I don't think diverging from upstream is accounted as an op= tion. Than you can: - use libinotify - promote my patch in upstream or here - do nothing and continue live with app crashing My patch (~1000 lines) have small (150 lines) code wrapper from plain C to glib, it is easy to rewrite/support. Also I publish C code to debug kqueue() backend without building with glib. IMHO FreeBSD desktop is unusable with current glib fam. We can discuss here what is right way to fix it, but users will migrate to other OSes where developers fix problems. This bug 2,5 years old, there is two stable solutions=3Dpathes and it does = not commited/fixed yet. In commercial or more an adequate community this situation is impossible! --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-199872-6497-NA4UtwPPz2>