On 3.6.2015 11:17, Jan Mareš wrote: > Thank you for very prompt response. As I mentioned in our previous > discussion, I use fibrils for pthread implementation and I would like to > achieve some level of preemptivness. The idea of having a constant > number of threads and letting fibrils be distributed amongst these > threads really appeals to me (and some preemptivness seems to be > necessary for QEMU, although the problem may be somewhere else as usual). > > The problem I mentioned manifests when using my implementation of > pthread and calling pthread_create lots of times (100000) . Maybe it is > also connected with the fact that ids of fibrils aren't unique - it's a > pointer to a memory that is likely to be reclaimed by another fibril > when the previous one is destroyed. > > For destroying a joinable pthread(fibril) in pthread_exit that hasn't > been joined yet I use fibril_switch(FIBRIL_TO_MANAGER) and later, when > the thread is joined I call fibril_destroy on the id of this fibril, > that due to my understanding should be dead (not present in any list > except fibril_list). I know that fibril_destroy should only be called on > a fibril that has never run, but it seems like the same thing that the > field clean_after_me does when I would use > fibril_switch(FIBRIL_FROM_DEAD). I also thought of a way to avoid doing > these unclean calls by merely using a condition variable. That way I > could only call fibril_switch(FIBRIL_FROM_DEAD) which would make the > whole thing much clearer. I will try that and I will get back to you if > I still run into this problem. In that case I will also try to reproduce > the same problem on plain fibrils so we can filter out my code.
You also mentioned some kernel panics and inconsistent thread counts. These are of the biggest concern to me because they almost certainly rule out the problem on your side. How do I reproduce these, were there any stacks reported by the panic, do you have a screenshot? Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
