Netlib rearchitecture meeting

July 1 1996:

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

• Modularize the old code
• Make sure the new code is thread safe
• Allow for third party protocol plugins
• Support the old client api (mostly)
• Support the newer JAVA URL connection API

"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 want to support a syncronous programming module for protocol plugins since an asyncronous module is easy to do wrong and any mistake by a plugin would block the navigator
• we want to make it easier to program the native protocol modules by using a syncronous model.
• ssl becomes much simplier if written syncronously
• The proxy team pointed out that they wanted threadsafe code but didn't think they wanted threads due to the expense of thread context switching.
• we decided to write a threaded test case to compare the performance of a new threaded design to their proposed asyncronous design

We also discussed problems with threads:

• Programmer education. Programmers using threads need to know how to consistantly write thread safe code
• We didn't come to any solution to this other than acknowledge the problem
• debugger/tools many current tools don't handle threads well. We need to be sure that we have the tools necessary to live in a threaded world
• Lou will be trying to make sure there is a solution to this problem
• threads can be expensive on some platforms
• The new netlib design will allow the reuse of threads to counter thread creation bottlenecks. User level threads can be used on systems that have poor context switching performance. (an NSPR issue)
• The proxy team pointed out that they wanted threadsafe code but didn't think they wanted threads due to the expense of thread context switching.
• we decided to write a threaded test case to compare the performance of a new threaded design to their proposed asyncronous design

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.