On Mon, Oct 19, 2009 at 11:33 AM, Clark Williams <williams@xxxxxxxxxx> wrote: > Just tried it on a RHEL5.4 and Fedora 11 system. The pthread_spawn(3P) > function is implemented using vfork(2) under the covers. Makes sense, > since the stated intent is to work without VM. > > Still, anyone wanting to create processes/threads in a realtime > environment needs to do that stuff up front, since there's a ton of > work required to make a scheduleable entity. Whether you're just > creating a pthread or you're generating a full-up process, memory will > have to be allocated and locks taken. Not sure I'd depend on > *anything* to do the right thing for me... Interesting. Last time I tested it, pthread creation could be realtime safe, if you allocate and mlock() a pool of memory beforehand and use pthread_setstack on the preallocated and pre-locked memory. However I for one did not think that any system call from a non-realtime thread will cause realtime threads of the same process to get blocked. I can't think of any other action that does that. Regarding the Ardour help menu issue, does this mean that using gtk APIs from a non RT thread of a process with RT threads is unsafe? Lee -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
