> > Why do you want to do this? > Several reasons: - easily implementable and replaceable scheduling policies (I have currently implemented the BVT policy which supports fair sharing and low latency response)
- being able to have ~ 100k "threads", yet not incurring extreme resource usage (mostly memory) + I have implemented an efficient message-passing core whch directly interacts with my scheduler (block on empty read and send on full msg queue). To achieve the same thing with POSIX, I'd need _at least_ 1 message queue / thread. Let's cut down the number to "only" 10k threads. How would the current Solaris kernel/userland cope with 10k SYSV or POSIX message queues? Is it possible at all to create such large number of them? Alternatively, I could use a single SYSV message queue and retrieve messages by type. But which data structure SYSV msg queues use? If it's a linked list, then retrieval by type is bound to get awfully slow even with a moderate number of messages. I _could_ write a new kernel scheduler module, but I'd first like to test my concepts in userland for easier debugging. But not even a new kernel scheduler module addresses the question of large # of message queues and resource consumption of large # of threads. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
