Linux-Development-Sys Digest #710, Volume #8 Thu, 10 May 01 15:13:11 EDT
Contents:
Re: shared DLLs written in C++, and _init(), _fini() ([EMAIL PROTECTED])
Re: Linux, streams and the standard library ([EMAIL PROTECTED])
Re: InterlockedIncrement(), InterlockedDecrement() ? ([EMAIL PROTECTED])
Re: Guid generator for unix. (Nick Andrew)
Re: why a separate process for each thread on Linux (Kasper Dupont)
Re: why a separate process for each thread on Linux (Eric Taylor)
Re: Linux, streams and the standard library (David Konerding)
Re: C++ Shared libraries on Linux - problem, HELP! ("Nick Lockyer")
Re: cache coherency, threads, SMP (Paul Repacholi)
Re: shared DLLs written in C++, and _init(), _fini() (David Konerding)
Re: shared DLLs written in C++, and _init(), _fini() ([EMAIL PROTECTED])
Re: shared DLLs written in C++, and _init(), _fini() (David Konerding)
C/C++ linux developpers based in Brussels ("DS Improve")
----------------------------------------------------------------------------
Subject: Re: shared DLLs written in C++, and _init(), _fini()
From: [EMAIL PROTECTED]
Date: 10 May 2001 11:04:32 -0500
>>>>> "DK" == David Konerding <[EMAIL PROTECTED]> writes:
DK> If everything is compiled and linked properly, your constructors
DK> should be called automatically... you do not need to override
DK> _init or _fini.
Actually, the reason for having _init() and _fini() in my C++ DLLs was
to provide the DLL with extra "hooks" to do whatever
initialization/cleanup might be necessary.
It would have been completely separate from contructors.
DK> Are you trying to link using "ld"? It might not work properly--
DK> when linking C++ code normally should use g++ as the linker
DK> instead of ld (although ld might do the same thing-- depends on
DK> the implementation). You do want to link with the standard
DK> libraries (IE don't use -nostdlib) otherwise, very bad things
DK> may happen.
No, I am linking using g++. Specifying -nostdlib causes static and
global C++ objects to not have their constructors called - which I
already mentioned in my earlier email.
I had already tried specifying -nostdlib which would get around the
multiple symbol definition errors, but would result in the static and
global C++ objects in the DLL to not have their constructors called and
hence not get initialized.
--
Salman Ahmed
To reply, remove "nospam." from my email address
ssahmed AT pathcom DOT com
------------------------------
Subject: Re: Linux, streams and the standard library
From: [EMAIL PROTECTED]
Date: 10 May 2001 11:06:18 -0500
>>>>> "DK" == David Konerding <[EMAIL PROTECTED]> writes:
DK> 7.0 is crap. Install 7.1. It's pretty good. I only had to do
DK> one thing to get STLport-4.1b6 (skip STLport-4.0 and get 4.1b6)
DK> to compile-- copy the <exception>,<new>, and <typeinfo> headers
DK> into a place where STLport could find them.
Are there any compelling reasons to go with STLport-4.1b6 over 4.0 ?
--
Salman Ahmed
To reply, remove "nospam." from my email address
ssahmed AT pathcom DOT com
------------------------------
Subject: Re: InterlockedIncrement(), InterlockedDecrement() ?
From: [EMAIL PROTECTED]
Date: 10 May 2001 11:07:42 -0500
>>>>> "VB" == Vyacheslav Burdjanadze <[EMAIL PROTECTED]> writes:
VB> Yes, you may use atomic_t when in kernel or write your own using
VB> POSIX mutexes
What is atomic_t, and where is it defined ?
--
Salman Ahmed
To reply, remove "nospam." from my email address
ssahmed AT pathcom DOT com
------------------------------
From: [EMAIL PROTECTED] (Nick Andrew)
Subject: Re: Guid generator for unix.
Date: 11 May 2001 01:22:46 +1000
Chronos Tachyon <[EMAIL PROTECTED]> writes:
>On Wed 09 May 2001 03:03, Sujeet Kharkar wrote:
>> Do any one knows of any utility for unix which is equivalent of guidgen on
>> windows ?
>You can do something similar with the following quick perl script. If you
>want an actual GUID (complete with brackets and dashes), you'll need to
>alter the program somewhat.
>--- cut ---
>#!/usr/bin/perl
>open(RND,"/dev/urandom");
>read(RND,$guid,8);
>close(RND);
>print unpack("H*",$guid), "\n";
>--- cut ---
... merely reduces the chance of collision, and does not eliminate it.
I thought GUIDs were supposed to be nominally globally unique, not just
show low chance of collision.
I'd suggest adding to the 8 random bytes, the FQDN of the local host
and return values from time() and getpid().
Nick.
--
Do not send me email copies of postings. Keep it in USENET please.
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: why a separate process for each thread on Linux
Date: Thu, 10 May 2001 17:41:51 +0200
Alexander Viro wrote:
>
> In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>
> >The processes created by clone(2) are quite tightly bound. I see
> >the very things there which make me want to avoid threads in the
> >first place (and use normal processes instead). For example, if
> >some code needs to chdir(2) to go deep into a directory tree, it
> >has to first suspend all other threads because chdir(2) will effect
> >their view of the world.
>
> Huh? Don't set CLONE_FS in flags and you have independent chdir for child.
Wouldn't it be nice to be able to share file descriptors
without having to share working directory. I bet it
wouldn't require many changes in the kernel to implement
that, the only problem is what flags should be used as
arguments to clone().
>
> --
> "You're one of those condescending Unix computer users!"
> "Here's a nickel, kid. Get yourself a better computer" - Dilbert.
--
Kasper Dupont
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: why a separate process for each thread on Linux
Date: Thu, 10 May 2001 16:07:41 GMT
Greg Copeland wrote:
> [EMAIL PROTECTED] writes:
>
> > That would mean each thread would have to have a stack allocation
> > within the address space to grow in, and this would all have to
> > come from a subset of the one address space all threads run in.
> > If you are allocating arrays within the stack space (e.g. alloca()),
> > then your stack space needs will be quite high, potentially. The
> > allocation of stack space itself will have to accomodate that,
> > perhaps with no advance knowledge of the space needs.
>
> Many thread implementations use the concept of page guarding on the
> stack to detect when it needs to grow. That is, when a read-only
> page is attempted to be written to, that is the highest point on
> the stack, you know it needs to grow. Now, the next step is to
> grow the stack logarithmically which means you shouldn't have to
> grow it many more times.
>
>
I've used a thread library that did just this. However, it still
needs to pre-allocate a stack's v.m. for each thread, since you really
can't
relocate the stack when growing, and it's probably not a good idea to have
a
non-contiguous stack (I'm not sure it's even possible). But, by
using the guard pages, and perhaps staining the stack at thread
init time, one can run a program with large stacks and prior to
exit call a routine to see how much stack was maximally used
by each thread. Then you can decide how much to allocate in
the future. Not perfect, but when you learn to live with a system
like this, you just don't allocate too much off the stack and avoid
recursion.
I recall the amiga o.s. which astonishingly allocated only 4k bytes
for a process stack (by default) and had no protection for overrun.
And it actually ran pretty well. So, if you know your own code, you
would normally just allocate, say, 10x the amount you think would
be the max and don't fret it because it's coming out of virtual memory.
Programs today might need a gig of space for data, but unless they
allocate arrays directly off the stack, or do recursion, they rarely use
much more stack than they did 10 or even 20 years ago. I don't find
that my threads use more than a normal process. I typically would
allocate 100k bytes per stack per thread which for 100 threads would
be only 10 meg of virtual address space.
BTW, Another advantage of having everything inside a single process
is that a checkpoint/restart is easier.
eric
------------------------------
From: [EMAIL PROTECTED] (David Konerding)
Subject: Re: Linux, streams and the standard library
Date: 10 May 2001 15:32:47 GMT
Reply-To: [EMAIL PROTECTED]
On 10 May 2001 11:06:18 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>>>>>> "DK" == David Konerding <[EMAIL PROTECTED]> writes:
> DK> 7.0 is crap. Install 7.1. It's pretty good. I only had to do
> DK> one thing to get STLport-4.1b6 (skip STLport-4.0 and get 4.1b6)
> DK> to compile-- copy the <exception>,<new>, and <typeinfo> headers
> DK> into a place where STLport could find them.
>
> Are there any compelling reasons to go with STLport-4.1b6 over 4.0 ?
Well, for one, it builds shared libraries in addition to static libraries
(useful if you want to link shared, so you don't end up with multiple copies
of the libray when you dlopen() C++ .so's linked against STLport. And it seems to
have some more support for wide characters, and glibc locales. I assume there are
also more bugfixes and better performance. I'm sure the release notes or the ChangeLOg
would be more accurate.
------------------------------
From: "Nick Lockyer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.development.apps
Subject: Re: C++ Shared libraries on Linux - problem, HELP!
Date: Thu, 10 May 2001 17:03:33 +0100
Why not add a message with source code and I am sure someone will help, I
would but I do not know much about shared libraries yet!
Billy Bob Jameson <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Hi.
>
> For some time now I am struggling to understand what's wrong with my way
> of building a shared library. Got a lot of answers from some ppl but
> still.
>
> Building a shared lib on UNIX is apparently a no-brainer. However, all
> my attempts end with "Segmentation fault" immediately after launching
> the test program that uses the shared library. So far I found out it's
> not because I use namespaces.
>
> More precisely, gdb displays just:
> (gdb) run
> Starting program: /work/src/testbin/testbin/.libs/testbin
> Program received signal SIGSEGV, Segmentation fault.
> 0x4000c1b6 in ?? ()
> (gdb) bt
> #0 0x4000c1b6 in ?? ()
> #1 0x40002855 in ?? ()
> #2 0x4001048f in ?? ()
> #3 0x40002382 in ?? ()
> #4 0x400020ae in ?? ()
> (gdb)
>
> This is all I get.
>
> If there is anyone here willing to get my sources (two kdevelop
> projects) compile them, run them and tell me then where I was wrong,
> he/she'll have my eternal gratitude.
>
> Additional info:
> RH 7.0 system upgraded from rpms to glibc 2.2.10
>
>
> TIA
> BB
>
>
------------------------------
Subject: Re: cache coherency, threads, SMP
From: Paul Repacholi <[EMAIL PROTECTED]>
Date: 11 May 2001 00:52:37 +0800
"D. Stimits" <[EMAIL PROTECTED]> writes:
> I assume some of the motherboards capable of dual celeron do not
> have the ability to follow direct cache-to-cache writes when one cpu
> cache is shared with another and the first is modified relative to
> main memory? Basically I'm wondering which, of the "oddball" x86
> cpu's, including celeron, thunderbird, duron, etc, cannot do an
> efficient cache-to-cache update?
Cache to cache protocols are death to performance unless it is a VERY
odd HW implementation. It seems to be a good idea, but for it to work,
the clocking domain must cover both CPUs, and the external caches and
bus interfacce to memory and the system. It can take forever to sync
up for the transfer. Been tried, and it is horrid. Much faster to just
dump the value to memory and the other CPU reads it, or it stalls its
interface waiting for the write and steals the data during the write.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
Spam-To: [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],
[EMAIL PROTECTED],[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David Konerding)
Subject: Re: shared DLLs written in C++, and _init(), _fini()
Date: 10 May 2001 16:54:08 GMT
Reply-To: [EMAIL PROTECTED]
On 10 May 2001 11:04:32 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>>>>>> "DK" == David Konerding <[EMAIL PROTECTED]> writes:
> DK> If everything is compiled and linked properly, your constructors
> DK> should be called automatically... you do not need to override
> DK> _init or _fini.
>
> Actually, the reason for having _init() and _fini() in my C++ DLLs was
> to provide the DLL with extra "hooks" to do whatever
> initialization/cleanup might be necessary.
>
Why are you going around the standard mechanism for doing this?
IE, using global constructors and static constructors?
> It would have been completely separate from contructors.
>
> DK> Are you trying to link using "ld"? It might not work properly--
> DK> when linking C++ code normally should use g++ as the linker
> DK> instead of ld (although ld might do the same thing-- depends on
> DK> the implementation). You do want to link with the standard
> DK> libraries (IE don't use -nostdlib) otherwise, very bad things
> DK> may happen.
>
> No, I am linking using g++. Specifying -nostdlib causes static and
> global C++ objects to not have their constructors called - which I
> already mentioned in my earlier email.
>
> I had already tried specifying -nostdlib which would get around the
> multiple symbol definition errors, but would result in the static and
> global C++ objects in the DLL to not have their constructors called and
> hence not get initialized.
Of course. You're omitting the necessary libraries when you use -nostdlib
which call the constructors.
Please do read the following:
http://www.informatik.uni-frankfurt.de/~fp/Tcl/tcl-c++/tcl-c++.html
as it will help you.
------------------------------
Subject: Re: shared DLLs written in C++, and _init(), _fini()
From: [EMAIL PROTECTED]
Date: 10 May 2001 13:40:26 -0500
>>>>> "DK" == David Konerding <[EMAIL PROTECTED]> writes:
DK> Why are you going around the standard mechanism for doing this?
DK> IE, using global constructors and static constructors?
Some of the symbols in my shared C++ DLL that will be dlsym()ed by
another app, are C++ objects. There are not primitive types but instead
C++ objects themselves.
So the app is obtaining pointers to these "exported" C++ objects via
dlsym().
My motivation to use _init() and _fini() in my DLLs was to do some
sanity checking wrt objects that were being created dyanamically in the
shared C++ DLL, but it is clear now that I need some other mechanism to
do that.
DK> Please do read the following:
DK> http://www.informatik.uni-frankfurt.de/~fp/Tcl/tcl-c++/tcl-c++.html
DK> as it will help you.
Thanks for the link, it is helpful.
--
Salman Ahmed
To reply, remove "nospam." from my email address
ssahmed AT pathcom DOT com
------------------------------
From: [EMAIL PROTECTED] (David Konerding)
Subject: Re: shared DLLs written in C++, and _init(), _fini()
Date: 10 May 2001 17:53:03 GMT
Reply-To: [EMAIL PROTECTED]
On 10 May 2001 13:40:26 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>>>>>> "DK" == David Konerding <[EMAIL PROTECTED]> writes:
> DK> Why are you going around the standard mechanism for doing this?
> DK> IE, using global constructors and static constructors?
>
> Some of the symbols in my shared C++ DLL that will be dlsym()ed by
> another app, are C++ objects. There are not primitive types but instead
> C++ objects themselves.
>
> So the app is obtaining pointers to these "exported" C++ objects via
> dlsym().
>
> My motivation to use _init() and _fini() in my DLLs was to do some
> sanity checking wrt objects that were being created dyanamically in the
> shared C++ DLL, but it is clear now that I need some other mechanism to
> do that.
Why not just have an 'extern "C"' function that passes the pointers to the objects
back, and have it do the sanity checking when it's called?
------------------------------
Reply-To: "DS Improve" <[EMAIL PROTECTED]>
From: "DS Improve" <[EMAIL PROTECTED]>
Subject: C/C++ linux developpers based in Brussels
Date: Thu, 10 May 2001 20:33:12 +0200
Hi,
You are looking for C/C++ linux skills in the following IT fields :
- industrial development (embedded linux, Lineo, Tini-Java, kernel drivers)
- internet/intranet solutions (Java, PHP, Javascript...)
- database development (mySQL, DB2,...)
- datawharehouse reporting
- linux and win32 integration/code migration
DS Improve is a consulting company based in Brussels/Belgium.
The members of our development team have university degrees in
Computer Sciences and work mainly with C/C++ and Linux, IRIX,
Win32 systems.
Competencies in :
-Analysis : Conceptual, Functional, Object Oriented (OMT/UML),
Components Design, Study and reduction of Algorithmical
complexity, Databases Design (Entity-Relation, Bachman),
System programming, processus optimisation, real-time
performances, focus on Security and Internet (e-biz)
-Languages : C/C++/STL, Java, Delphi, Kylix, Assembler x86/68000,
ADA, PHP, COM, ActiveX, SQL, Pascal, Javascript, HTML,
XML, ESQL/C (DB2, Informix, mySQL, Sybase, Oracle, Interbase)
and general interest in Object Oriented Languages
-Algorithms : Trees, graphs, complex hybrid structures, study of
complexity, parallelisation, cryptography
-Scripts : bash, ksh, csh, awk, python, perl, php
-Systems : Linux, IRIX, Windows NT/2K/95/98/Me, MS-DOS, generic Unix
(core programming, scripting, system administration)
-Development : GNU C/C++, SGI MIPSpro cc/CC (IRIX MIPS & Linux IA64),
Environment Visual C++ (ATL/COM), Rapid Application Development
(Borland VCL/CLX Tools : C++ Builder, Kylix, Delphi),
KDE 2.x/Qt 2/KDevelop, Java JDK 1.1, SNIFF+, Devpak 68000,
x86 Masm/Tasm, OpenWindows, Forms (Motif), linux kernel
development, Apache, LaTeX
-Hardware : IBM PC/compatible workstations/servers, Silicon Graphics
platforms O2/Octane/Onyx/Origin, embedded systems (Lineo, TINI, ...),
HP, Sun, IBM/AIX, PLC drivers (Programmable Logic Controllers
:
Simatik S5, S7, ...)
As an add-on value, we are official Ecrix (storage), SuSE/linux and
SGI (Silicon Graphics) resellers. That means that you can ask us to
design, tune and offer complete custom integrated solutions suited
to your needs, based on these products or others.
contact us at: [EMAIL PROTECTED]
DS Improve
European Erasmus Business & Innovation Center
Avenue Joseph Wybran, 40
1070 Brussels - Belgium
phone : 32-2-529-59-41
fax : 32-2-529-59-54
http://www.dsimprove.com
Thanks for your time and have a nice day
DS Improve team
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
