Return to BSD News archive
Xref: sserve comp.windows.x.i386unix:1583 comp.os.386bsd.questions:2539 Newsgroups: comp.windows.x.i386unix,comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!convex!darwin.sura.net!wupost!csus.edu!netcom.com!hasty From: hasty@netcom.com (Amancio Hasty Jr) Subject: Re: XFree1-2 + 386BSD performance Message-ID: <hastyC78F50.364@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <1t9mg3INNoep@srvr1.engin.umich.edu> <1ta5ro$ip5@zaphod.axion.bt.co.uk> <1tarqr$jmv@binkley.cs.mcgill.ca> Date: Tue, 18 May 1993 16:58:11 GMT Lines: 30 In article <1tarqr$jmv@binkley.cs.mcgill.ca> storm@binkley.cs.mcgill.ca (Marc Wandschneider) writes: >In article <1ta5ro$ip5@zaphod.axion.bt.co.uk> lessen@axion.bt.co.uk (Lee Essen) writes: >> >>I think this unquestionably a big argument in favour of shared libraries, some >>of use can afford to have 32 Meg systems, and even those that do probably dont >>like the idea of 28 Meg of it filled with several copies of the static libraries. >> >>Why is there so much 'anti-shared-library' feeling? > I am beta testing shared library support and we are running into minor problems. When they are ready they will be posted :-) About bsd performance, one side of the equation is the support for shared libraries, the other side is that drivers execute at ipl level thus locking out servers like X. What people have done in the past is to split the driver into at least two parts, one basically, that handles interrupts and writing to the devices and the other at an interruptable priority. So if we get shareable library support we will still run into performance problems while compiling. Cheers, Amancio -- This message brought to you by the letters X and S and the number 3 Amancio Hasty | Home: (415) 495-3046 | ftp-site depository of all my work: e-mail hasty@netcom.com | sunvis.rtpnc.epa.gov:/pub/386bsd/incoming