Feb 15 16:47:40 <ssp>	One thing that I definitely see, is pixman itself doing multithreaded rendering
Feb 15 16:47:47 <sanooj>	really?
Feb 15 16:47:58 <Company>	i think it can
Feb 15 16:48:01 <sanooj>	I would think that the app is in a better position to do multithreading.
Feb 15 16:48:23 <Company>	but then, the thread tests crash all the time
Feb 15 16:48:42 <Company>	but pixman needs to be thread-aware to do stuff like choosing the implementation safely
Feb 15 16:49:03 <Company>	or caches
Feb 15 16:49:35 <ssp>	sanooj: Can you get enough granularity at the image level? 
Feb 15 16:50:13 <ssp>	I'm thinking splitting large composite operations vertically and then have threads composite a strip each
Feb 15 16:50:51 <ssp>	You can also imagine feeding large amounts of compositing operations to pixman at once, then have it go off and render it
Feb 15 16:51:18 <ssp>	That is something ickle has suggested too
Feb 15 16:51:50 <sanooj>	I can see all those things being possible too, but is it really worth the effort?
Feb 15 16:52:43 <sanooj>	you'd likely need to change the way pixman is being driven by apps to make use of the multithreading.
Feb 15 16:53:02 <sanooj>	except for the big-composites-being-split case.
Feb 15 16:53:39 <sanooj>	but even then, I think the application ought to be in control of the threading.
Feb 15 16:53:47 <sanooj>	putting threading inside a library is just a Bad Idea(tm).
Feb 15 16:54:45 <sanooj>	internal locking, queue management, signal masks, fork-safety, async safety, ...
Feb 15 16:55:05 <--	pachi (~pachi@84.76.216.176) has left #cairo ("Information wants to be free")
Feb 15 16:55:24 <sanooj>	it's enough to do one's head in even when one is in total control of the app. nevermind if something starts spawning thread behind your back.
Feb 15 16:55:27 <--	AfC has quit (Quit: Leaving.)
Feb 15 16:55:32 <sanooj>	threads*
Feb 15 16:56:04 <ssp>	Well, glib is spawning threads behind the backs of all GNOME applications these days
Feb 15 16:56:22 <sanooj>	if your friend jumps off a bridge would you too?
Feb 15 16:57:00 <ssp>	Eh, they haven't hit the ground yet, so it's probably ok.
Feb 15 16:57:24 <ssp>	I don't know. There is also Grand Central Dispatch
Feb 15 16:58:31 <ssp>	Multi-core CPUs are a fact of life - I just don't think there will be enough parallelism in most apps to take advantage of them by themselves
Feb 15 16:58:56 <sanooj>	and they've butchered the posix api by spawning threads inside their frameworks.
Feb 15 16:58:57 <ssp>	There is also X - the only way to sanely multithread the X server is to do it in the rendering routines
Feb 15 16:59:24 <Company>	sanooj: i think spawning threads needs to be a lot more common
Feb 15 16:59:25 <nickle>	or move the rendering out of X
Feb 15 16:59:44 <Company>	sanooj: i'm sick of libraries that insist on being single threaded and then take 90% of the cpu
Feb 15 16:59:53 <Company>	of _one_ cpu
Feb 15 17:00:07 <sanooj>	Company: death to you and all your progeny!
Feb 15 17:00:17 <ssp>	nickle: Into its own process you mean?
Feb 15 17:00:22 <Company>	sanooj: death to you and your old school "we need signal mask safety"
Feb 15 17:00:34 <nickle>	but if that means I can power down the other 63 cpus yeah
Feb 15 17:00:36 <Company>	nickle means wayland
Feb 15 17:00:38 <sanooj>	Company: hahaha
Feb 15 17:00:47 <sanooj>	Company: seriously, multihreading is fine and all, but please, *please* let the application be in control of all resources.
Feb 15 17:01:16 <Company>	sanooj: dunno, i'd like it if threads weren't considered a resource
Feb 15 17:01:25 <Company>	sanooj: kinda like ram
Feb 15 17:01:26 <nickle>	just need to solve the shared resources...
Feb 15 17:01:33 *	nickle handwaves
Feb 15 17:01:50 <sanooj>	Company: hello to cloud 9 ;)
Feb 15 17:03:00 <Company>	cloud 9?
Feb 15 17:03:56 <sanooj>	in this case, http://en.wikipedia.org/wiki/Cloud_nine_(Tensegrity_sphere)
Feb 15 17:04:28 <sanooj>	libraries spawning threads is just incredibly rude.
Feb 15 17:04:43 <Company>	dunno
Feb 15 17:04:54 <sanooj>	you can't even unload them sanely without being extra careful.
Feb 15 17:04:57 <Company>	almost all libs i work on do that these days do that liberally
Feb 15 17:05:06 <Company>	and none of them support unloading
Feb 15 17:07:40 <sanooj>	I'm not saying don't do it at all.  I
Feb 15 17:07:50 <sanooj>	'm saying do it in a way that allows the app to control it.
Feb 15 17:08:20 <Company>	dunno
Feb 15 17:08:33 <sanooj>	see, that's the problem. ;)
Feb 15 17:08:40 <Company>	in the pixman case it's rather easy - pixman_spawn_threads (no);
Feb 15 17:08:52 <Company>	gstreamer and gio won't work without threads
Feb 15 17:10:13 <sanooj>	that's fine for gstreamer and gio.  they can go burn with libvlc and libgps and all the other insane libraries.
Feb 15 17:10:47 <Company>	why do you think threads are a rare resource?
Feb 15 17:11:02 <sanooj>	not rare.
Feb 15 17:11:12 <sanooj>	spawning threads messes with other APIs in the system
Feb 15 17:11:30 <Company>	not with any sane one
Feb 15 17:11:43 <sanooj>	heh.
Feb 15 17:12:07 <sanooj>	a library shouldn't be making those kinds of judgement calls.
Feb 15 17:12:35 <Company>	no
Feb 15 17:12:44 <sanooj>	I agree that threading _shouldn't_ mess with system APIs but we live in a messy world of unix heritage.
Feb 15 17:12:50 <Company>	it's common knowledge that spawning threads is fine
Feb 15 17:13:05 <Company>	and if it's not you fix your posix
Feb 15 17:13:14 <sanooj>	it's a common delusion, I agree. wishing problems away doesn't make it so.
Feb 15 17:13:27 <sanooj>	and posix is totally on crack with respect to APIs and threading.
Feb 15 17:13:43 <sanooj>	when you spawn a thread all of the sudden a whole bunch of single threaded system calls aren't defined anymore.
Feb 15 17:14:50 <Company>	so don't use them or use an OS where they are defined
Feb 15 17:15:04 <Company>	we don't need to build on 1970s APIs
Feb 15 17:15:16 <Company>	i agree that in the 70s it was rude to just spawn threads
Feb 15 17:15:20 <sanooj>	lol
Feb 15 17:15:45 <Company>	in the 60s it was probably rude to just malloc
Feb 15 17:16:47 <Company>	(and in the 50s you were a bad guy if you used the stack?)
Feb 15 17:17:00 <Company>	(back when stack still went uphill)
Feb 15 17:17:16 <sanooj>	again, I'm not saying don't use multithreading.  I'm saying not to do it recklessly.
Feb 15 17:18:33 <DrNick>	I don't think anybody does retarded things if you spawn threads which don't use any of those non-reentrant functions
Feb 15 17:18:52 <sanooj>	signals get routed to random threads
Feb 15 17:19:04 <sanooj>	this is a huge problem in apps which actually do something with signals.
Feb 15 17:19:29 <sanooj>	also you need to be able to shut down a thread cleanly in an app specific way.
Feb 15 17:19:30 <DrNick>	I doubt any of the non-reentrant functions are async signal safe anyway, so it's the apps own fault
Feb 15 17:19:51 <--	asac has quit (Read error: Connection reset by peer)
Feb 15 17:19:58 <sanooj>	I'm not even talking about non-reentrant functions but things like being able to fork.
Feb 15 17:20:08 <DrNick>	you can't fork from signals either
Feb 15 17:20:33 <sanooj>	what?
Feb 15 17:20:38 <sanooj>	that's totally missing the point.
Feb 15 17:20:58 <DrNick>	oh, you mean forking from threads?
Feb 15 17:21:06 <sanooj>	forking a multithreaded app, yes.
Feb 15 17:21:10 <sanooj>	needs the special attention.