Adam Thompson <[email protected]> writes: > A sort of multi-process multi-threaded mechanism.
The biggest concern is that we have to share a whole bunch of HTTP-related state across process boundaries. Multi-threading sounds like the answer. Take that state that needs to be shared across threads, and encapsulate it behind a well-defined interface to insure proper synchronization, consistency, etc. We will have to be much more careful about the use of anything global. Another solution might be to wrap all of our networking code in its own process. Let the edbrowse, edbrowse-js, and other processes communicate with it using an API based around messages exchanged over pipes. Again, this insures proper and synchronized access to this huge blob of global state. Or how about allowing edbrowse-js to call into the main edbrowse process to make HTTP requests? Does js really need to have direct, unmediated access to HTTP, or could it send messages over its pipe to the parent process saying "GET <url>", "POST <url> <data>", and so forth? -- Chris _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
