:Once the mutexes are in place the underlying implementation can
:change pretty easily from task switching always to only task
:switching when the mutex is owned by the same CPU that I'm running
:on. (to avoid spinlock deadlock)

    That makes *NO* *SENSE* Alfred!   So the first step is to introduce
    every single possible feature under the sun, requiring massive reworking
    of the code, even if it means the system becomes massively unstable,
    inefficient, and starts crashing and burning, and then only *later* we
    remove the features that don't pan out?  That is the development model
    you are using for -current?

:I agree that task switching _might_ be a performance hit, however
:that can be fixed by only task switching when in interrupt context.
    WILL be a performance hit.  WILL introduce major bugs.  IS unnecessary,
    DOESN'T make any sense whatsoever, is at CROSS PURPOSES with goals
    already stated (not having any serious contention in the first place),
    REQUIRES massive changes to the code with not a chance in hell of 
    producing an equivalent performance improvement for the trouble.

    There is no 'remains to be seen' here Alfred.  This is setting up
    -current for a fall, one that could be entirely avoided *now*
    if you people would sit down and start thinking about what you are

    Remember when Dyson introduced ten thousand cool things all at once
    and didn't debug them?  Remember how long it took DG to the system
    back into some semblence of shape after that?  Remember that, even after
    all that hard work, there were still literally hundreds of hard to find
    bugs that DG couldn't find that it took Alan, DG, and I a year's worth
    of work beyond all the work DG had already done to cleanup?  Is that
    what you want to happen to current?  Because that is where current is
    headed right now.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to