But anyway, I also wonder if the threaded version shouldn't be the default behaviour of cyclone's coll, because we always have the bang output to rely on and tell us when it is done anyway. The whole purpose of its existence and design choice seems to be that anyway... it only makes sense if it is undetermined...
so I'm thinking that if one wants the pd related behaviour that you should add it as a flag, say "threaded 0"
I don't think it should be threaded by default either. I think it came up earlier on the list that Windows machines were having issues with coll's threading? I remember reading somewhere that pthreads was unix only and there's a separate Windows way of doing threading, which isn't in coll quite yet.
I did add back the bang out the 3rd inlet on instantiation when a file argt is loaded. There was a clock x->x_clock that was only instantiated in the threaded version that I needed to use because the methods that load the file arg coll_bind -> collcommon_doread return before coll_new returns so the object exist yet so there's no outlet to bang to (at least that's what I think was going on...). I did this by adding a check in coll_bind, where msg is the thing returned by collcommon_doread:
if(msg->m_line > 0) clock_delay(x->x_clock);
but that may have been the thing that screwed up the correct order of things. In any case, I'll have to look at it more...
Derek