* Emerson Clarke <[EMAIL PROTECTED]> [2006-12-30 15:15]: > My complaint, if you want to call it that. Was simply that > there are seemingly artificial constraints on what you can and > cant do accross threads.
They are not artificial. The options for making the API of a library with complex internal data structures thread-safe are: • Expose all implementation details that will require synchronisation, including internals that will be changing frequently, so that you can punt the issue to client code. • Add a lot of hard-to-debug code with a myriad checks to synchronise access to internal data structures behind the API facade, including measures like adding indirections to do queuing where necessary, and the like. If you don’t take great pains to get this design right, you are likely to create locking dependencies that will compromise concurrency and degrade performance. Strange bugs are likely to plague you whenever users try to deploy the code in new environments. • Tell API clients they can’t do certain things. Which of these seems sensible to you? > If i have a linked list, i can use it across threads if i want > to, provided that i synchronise operations in such a way that > the list does not get corrupted. That scenario is meaningless as an analogy. The right analogy would be if the linked list were an internal datastructure that is part of the implementation of a library but not of its public API. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
