Hi, Jakub Assuming you are creating threads using thread_create(), I think you are > hitting: >
thank you for your response. Your assumption is correct. > #9 Current fibril model can confuse kernel's view on threads > > http://trac.helenos.org/ticket/9 > > What most likely happens is that the current fibril gets migrated to > another thread when it blocks. This is to be expected due to the way our > async framework works. With the async framework, the normal threads > become something like execution containers, or, if you like, virtual > CPUs, where fibrils can execute. > > One either stays away of the async framework completely and then threads > are the primary execution entities, or one uses async framework and > fibrils are the primary execution entities. Most of the HelenOS uspace > uses fibrils and async framework. The only exception is ns. > I think I'm starting to understand what's happening here. The thread id is stored at the bottom of the stack, when a fibril goes from one thread to the other, it changes threads stack pointer and thus, when this thread asks for its id, it receives a different one. But then the whole THE reference in the kernel is wrong - or at least its thread and cpu members. Please correct me if I'm wrong, I've tried to find some materials on the topic of the HelenOS and its fibrils and async framework, but found only a small description written by MD in some book touching the topic. I'm keen to read more about this, so I would be grateful if you could recommend something. I realized it's hard to avoid using the async framework in pcut tests, because libpcut implementation is based on the fibril functionality. I understand that fibrils use cooperative scheduling. I found GNU portable threads, which implement pthread as cooperative as well. So there should be no harm in implementing pthread using the async framework. Please let me know what do you think, Jan
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
