Netlib rearchitecture meeting

July 1 1996:

The meeting began with a discussion of the redesign goals. These were the goals listed:

"Threads" were also listed as a design goal but the room couldn't agree to it so it was removed from the list.

The meeting then proceeded into a discussion about why threads were used in the new design. These were the reasons given:

We also discussed problems with threads:

It was pointed out that we could meet most of our goals by using a threadsafe asyncronous module for the netlib and not use threads. This would trade the complications of threads for the complications of the asyncronous model, but it would be isolated to the netlib + ssl. This discussion went on for quite a while with no clear outcome. Since we were not coming to consensus we instead moved on to covering the design spec.

Instead of covering the design in this document you should read the actual design spec

At the end of the design discussion and alot of question and answer we again revisited the question of whether threads were a good idea for the new netlib architecture. The group agreed that the design proposed helped to eliminate many of the dangers of adding threads to otherwise non-thread safe code. The event queue model for interaction between the front end and the netlib isolated the most problimatic areas of the codebase into a controllable queue. By the end of the meeting there little strong opposition to the design and many people were strongly in favor of it. Based on that rough consensus the design will proceed, with the condition that better tools need to be found for all of our supported platforms.