gnb@bby.oz.au (Gregory N. Bond) (05/14/91)
Does anyone have any experience or advice for creating shared library
versions of widget sets?
In particular, what files or chunks of file should be put in the .sa
file? I notice that none of the Xaw library is in an sa file, and
only a few wrapper functions from Xt.
My reading of the SunOs manual suggests that as a minimum the class
record should go there, and probably not much else.
Anyone illuminate the cost/benefit of splitting out the .sa stuff?
Greg.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnbcasper@fwi.uva.nl (Casper H.S. Dik) (05/14/91)
gnb@bby.oz.au (Gregory N. Bond) writes: >Does anyone have any experience or advice for creating shared library >versions of widget sets? >In particular, what files or chunks of file should be put in the .sa >file? I notice that none of the Xaw library is in an sa file, and >only a few wrapper functions from Xt. All data referenced by user programs should be exported. If you don't do this, the resulting executable will need runtime relocation. The library is still shared, the executable isn't. The X consortium got that wrong. >My reading of the SunOs manual suggests that as a minimum the class >record should go there, and probably not much else. Indeed, it should. >Anyone illuminate the cost/benefit of splitting out the .sa stuff? Putting data in .sa costs (cost only paid for executables which use data from the .sa part): - larger executable. - data consists in both the shared library data part and the data segment. But you gain: - no runtime relocation of your binary: - binary is shared among processes (current cost: +/- 250k/xterm) - faster startup Data put in .sa should also exist in .so part (if referenced by any library function). Some executable code can be put in the .sa part: - functions used in address comparisons - short, fast functions that are used a lot. (E.g. Sun's function implementation of the ctype macros) Cost: More VM use. Gain: Somewhat faster execution. It should be clear that with Sun's implementation of shared libraries, data is evil. X11R4 is a major offender in this respect. VM consumption of an xterm process: statically linked: X dynamically linked with properly constructed X lib X+60k (large amounts of duplicated and unneeded data) dynamically linked with X libs as distributed: X+250k (unshared executable) Be aware that the .sa and .so must have exeactly the same revision number. (E.g. both 1.4.1 and not 1.4.1 and 1.4) -- JANET: | Casper H.S. Dik The English Network - Another Joke | casper@fwi.uva.nl
rws@expo.lcs.mit.EDU (Bob Scheifler) (05/15/91)
The X consortium got that wrong. Or perhaps Sun got the design wrong. :-) The problem with putting data in the .sa file is that you significantly increase the number of ways in which binary-incompatible changes can be made to the library. You also need to export a fair number more functions that could otherwise be static (giving programmers more chances to play games they shouldn't play :-). The difference in memory consumption however is, as stated, considerable.
kre@cs.mu.oz.au (Robert Elz) (05/22/91)
rws@expo.lcs.mit.EDU (Bob Scheifler) writes: >The problem with putting data in the .sa file is that you significantly >increase the number of ways in which binary-incompatible changes can be >made to the library. I don't understand this? Only initialised data that applications will actually reference is generally intended for the .sa file isn't it, not private data in the library. No matter how you change this kind of data its going to lead to binary incompatability and the need to recompile, unless you are very careful in what you do (adding fields to the end of a struct which no-one cares about the size of, etc). >You also need to export a fair number more functions >that could otherwise be static Really? Why? Isn't that the same thing? kre
rws@expo.lcs.mit.EDU (Bob Scheifler) (05/28/91)
>The problem with putting data in the .sa file is that you significantly >increase the number of ways in which binary-incompatible changes can be >made to the library. I don't understand this? Only initialised data that applications will actually reference is generally intended for the .sa file isn't it, not private data in the library. It was my misunderstanding that it would be necessary to place the widget class structures themselves in the .sa part, not merely the pointers to them.
samborn@sunrise.com (Kevin Samborn) (06/03/91)
/\/\ On 27 May 91 19:34:51 GMT, Bob Scheifler said: >The problem with putting data in the .sa file is that you >significantly increase the number of ways in which >binary-incompatible changes can be made to the library. >I don't understand this? Only initialised data that >applications will actually reference is generally intended for >the .sa file isn't it, not private data in the library. Bob> It was my misunderstanding that it would be necessary to place Bob> the widget class structures themselves in the .sa part, not Bob> merely the pointers to them. I have been following this, but now I am lost. Finally, at least to clear it up for me, where are you supposed to put the widget class structures? In R4, they were put in the .so part, right? Where do they go now? Does this change the structure of these files? Widget.h WidgetP.h Widget.c Last, if you are just supposed to put a pointer in the .sa part, how is that supposed to look? Just like this?: extern WidgetClass myWidgetClassPointer; Thanks, kevin samborn -- kevin samborn "Anatidaephobia: The fear that somewhere, samborn@sunrise.com somehow, a duck is watching you." ...!uunet!ezx!samborn
kre@cs.mu.oz.au (Robert Elz) (06/03/91)
samborn@sunrise.com (Kevin Samborn) writes: >Last, if you are just supposed to put a pointer in the .sa part, how >is that supposed to look? Just like this?: > extern WidgetClass myWidgetClassPointer; Definitely not that - only initialised data goes in the .sa file. I think I see Bob's point now ... anything in the .sa file is (effectively) part of the application, not part of the library for these purposes, so any data that anything in the .sa file refers to should (ideally) go in the .sa file too. Clearly that means that if a pointer to a Widget Class is there, the Widget Class should be too - which means its initialised value will be compiled into applications, and can't be changed later in the shared library. What's more, the class struct refers to procedures in the libraries, so they can't really be static, which they otherwise could. I'd like to actually try some variations sometime - but I think I might just wait till R5 now. I suspect that the eventual conclusion might be to put stuff in the sa file is you're largely an X user, rather than a developer - ie: if you're rarely (if ever) going to actually change any of the widgets - and if one is changed in a "bad" way you would be willing to relink everything that uses it (ie: losing much of the benefit of shared libraries). If you're a developer, you're probably better off lumping everything in the .so file, and suffering the preformance losses. kre