Yes, I'm scared to death of threads. The readsf~/writesf~ objects do use them (there's no alternative) but my experience in general is that it's very hard to maintain threaded code if you want a high level of reliability (which I do in Pd)...

I'd be interested someday in trying to make a general framework for I/O operations (soundfiler, for example) using asynchronous reads and writes, and perhaps the best way to do this would be using threads. But I wouldn't assume so. As to graphics updates, I think they can be managed much better than they are now by careful scheduling, without having to use threads. I dont' plan to mess with this in the upcoming version though, since I've finally got it almost all working.

cheers Miller

On Sun, Jun 23, 2002 at 11:10:41PM -0400, Larry Troxler wrote:

On Mon, 24 Jun 2002, ydegoyon@free.fr wrote:

...

hi, all,

annoyed by some recurrent issues in PD, i made the following patches to PD's sources :

d_soundfile.c : load the sounfile in a thread to avoid audio dropouts. this patch concerns the "soundfiler" object.

s_inter.c : send messages to the GUI using a message buffer and a thread to avoid audio dropouts.

this introduces a lot of threads and Miller objected once using threads is dangerous.

so, if you like danger, you might try these.... it's experimental still but with the help of some beta-testers, it might get consistent soon.

cheers,

sevy/yves

Wow! I hope these get accepted - particularly if you indeed have fixed the GUI problem (it being not properly multithreaded, that is), this indeed something everyone has been looking forward to.

Did Miller really object to using threads, saying that they're dangerous? In what context?

Using threads *is* often quite tricky to get right, of course.

Larry