Thorsten,
Not sure the other thread waits on another program - it may just be late in starting up (tried to check the timeout?). If that's not it - maybe things are happening in the wrong order on m68k. You might be able to find out what happens in which order by logging messages from all threads involved on a fast architecture, and m68k.Is there another thread supposed to join in and break the deadlock? Lock initialized wrong?I guess yes at the first one, no at the second one, I didn’t see much m68k-specific code there, and things appear to work on the other arches (plus, Qt4 has similar issues). As I said earlier, I have almost zero skills in parallel programming. My current guess is that when a thread waits on another thread which wait()s on another program, things lock up.
I'm not an expert in parallel programming by any stretch - though I have debugged code using SYSV IPC semaphore locking both local and across networks. Log messages may change timing but if it really is something like program startup timing this is not going to matter.
Since gmail is my primary outgoing service, I did tend to notice that a lot. I'll try via my uni's mailhost (though they get themselves on blacklists a lot as well, thanks to clever spear-phishing and lotsa windoze boxes).(hoping this will reach you via one of the lists, as you appear to refuse mail from me otherwise)Not from you specifically, but Google Mail has finally made it onto the blacklist indeed. (Lots of spam and unresponsive abuse@)
Cheers, Michael