You're saying, "it's hard." Are you also saying, "abandon all hope because it's hard."
Are any of the parties herein indirectly suggesting or asserting that the dragonflybsd effort (visa vi api-centric model) is doomed or ridiculous or wrong minded? Either intrinsically or just because it's hard. Because dragonflybsd's site states, in part, "...What are the potential goals for the next release? Multiprocessor-safe networking without the Big Giant Lock..." Matthew Dillon, the principal, seems to be well down the path with some breaking-the-mold means and ways. dfbsd isn't finished yet. And, yes, it should be subject to a vetting along its way. But is a well principled and by all appearances a using a disciplined approach. And, in fact, I've often thought that a union (co-ompetition, if not co-operation) of obsd and dfbsd would make a whole lot of sense. -----Original Message----- From: Matthew Weigel <[EMAIL PROTECTED]> To: OpenBSD <misc@openbsd.org> Subject: Re: Multi-Threaded SSH/SCP made by university of Puttsburgh Date: Thu, 14 Feb 2008 01:25:15 -0600 Mailer: Thunderbird 2.0.0.9 (Windows/20071031) Delivered-To: [EMAIL PROTECTED] Geoff Steckel wrote: > I'm sure you're extremely bright and can do it. It's not about me. If the OpenBSD developers *can't*, they should just drop any efforts to refine the big SMP lock, any effort to provide kernel threads, any effort to make libc reentrant. And if they do that, then a) threads will have zero performance value, but b) splitting work across threads will have minimal performance value too. To put it another way, if they can deal with it in the kernel, if they can deal with the vastly wider array of security problems that can crop up in device drivers... they can handle multi-threaded application code.
