Date: Wed, 23 Apr 1997 03:12:29 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: rssh@cki.ipri.kiev.ua Cc: msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Dynamic linking libraries [Q] Message-ID: <199704221742.DAA16750@genesis.atrad.adelaide.edu.au> In-Reply-To: <335CAB59.7B13@cki.ipri.kiev.ua> from Ruslan Shevchenko at "Apr 22, 97 03:13:09 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Ruslan Shevchenko stands accused of saying: > > i.e. you want describing of major differences between .dll and .so > models, wich important for me ? > So: > > 1. let we have program a.out , that use library libb.so > when I start new a.out, each time new copy libb.so linking with > a.out during execution of it. > All static variables in libb.so are unique for each copy of a.out. > (on this based, for example, strtoken) > in .dll model, one example of code is shared between multiple > versions of a.out Er, I'm not sure I follow the difference here. In each invocation of an exectuable using a shared library, statics are common, yes. I don't understand the second part though; with shared libraries, one copy of the code is also used, regardless of how many processes are using the library. If you are referring to interprocess communication using static variables in a DLL, I think people here might be very ill. 8) > 2. Usially, a.out bind with libb.so during linkink by ld(1). > Then, after caling nlist(3) a.out linking with libb.so during > execution of process. > in .dll model we can call symbols from dll, which unknown on > comilation step. You can do this with shared libraries too, as long as you know the name of the library, and the name of the function. > 3. DLL can be loaded to memory and relaeased from memory by system > calls. You can do this with shared libraries too. You should read the dlopen(3) manpage. > Why it is interest: > 1. It is allow to do API-call IPC without network connections. This is gross beyond belief. How can you know how many other processes are using the same IPC token? > 2. OS servers, drivers, and so on can be do in this model. > for example, IMHO it's the best way to do "server of scripting > language", What advantage does this have over the scripting language in a shared library? You can't possibly want state to be shared amongst arbitrary invocations of the interpreter? > my current interests - is the general model of CORBA: the problem is, > that without it I can't do CORBA object, living in OS, which can fast > communicate with programs on the same mashine (without RPC on > localhost). TBH, I know little or nothing of CORBA, but if you want fast IPC, I suggest using mmap() on an agreed temporary file, and your own locking primitives. This will let you control the scope of your communication, something you wouldn't be able to do with the "dll" model you propose. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704221742.DAA16750>