Linux-Development-Sys Digest #707, Volume #8 Wed, 9 May 01 18:13:12 EDT
Contents:
Re: background process survive session close? (Greg Copeland)
Re: serial port autodetection (Greg Copeland)
Re: why a separate process for each thread on Linux (Eric Taylor)
Re: cache coherency, threads, SMP ("Norman Black")
Guid generator for unix. ("Sujeet Kharkar")
Re: why a separate process for each thread on Linux (Alexander Viro)
Re: Guid generator for unix. ([EMAIL PROTECTED])
Re: Guid generator for unix. (Chronos Tachyon)
Re: Checking if a pointer is valid ([EMAIL PROTECTED])
InterlockedIncrement(), InterlockedDecrement() ? ([EMAIL PROTECTED])
Re: why a separate process for each thread on Linux (Juergen Heinzl)
Re: why a separate process for each thread on Linux (Dragan Cvetkovic)
shared DLLs written in C++, and _init(), _fini() ([EMAIL PROTECTED])
----------------------------------------------------------------------------
Subject: Re: background process survive session close?
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 09 May 2001 14:11:34 -0500
A lot of people use screen for this very reason. In fact, you
can do cool things like this. First, run screen on you console.
Second, start your application. Third, log out. Now, go home
and telnet to the box that is running the application. Now,
run screen again, telling it to attach to the instance that you
previously had running. Bam...right where you left off. This is
very slick.
greg
Eric Taylor <[EMAIL PROTECTED]> writes:
> I know I have done this:
>
> program ... &
>
> close session window (or telenet session if remotely connected)
>
>
> and the program _sometimes_ remains running. I can't
> determine when or what causes this. But, I actually want this
> behavior, without needing to modify source code.
>
> Any ideas what is going on and is there a legit way to run
> a program or script in the background and then be
> able to quit the controlling terminal window w/o killing the
> background job?
>
> thanks
> eric
>
>
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
Subject: Re: serial port autodetection
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 09 May 2001 14:18:22 -0500
Back in the days of BBSs, we used to assume that the first characters
received would be a space or cr. So, we set a default baudrate and
cycled through them until we got a hit. We always assumed N81, otherwise
it got to complex to do reliably with a standard UART used in PCs.
I guess if you think you really need to do this and you can ensure the
first value that is recieved, repeatedly until you can "sync", you could
make a table of possible values for each "hit". Once you had a hit, then
you'd be able to exclude a vast majority of the possible values. From the
hits, you could infer the current setting. You could then repeat until
you were able to sync. Not sure how reliable this would be though.
Greg
[EMAIL PROTECTED] (Grant Edwards) writes:
> In article <[EMAIL PROTECTED]>, Javier Loureiro Varela wrote:
>
> >>> maybe, they use some kind of low level protocol for this
> >>>autodetection (like LAPM for error checking)...
> >>
> >>Nope, they don't. They just assume that the first thing they
> >>see is going to be an 'A'. You measure the length of the start
> >>bit to determine baud rate, and then look for the stop/parity
> >>bits.
> >
> > there is any way to do that?
>
> Not with a regular PC serial port.
>
> > How can I know those data?
>
> You hook the Rx Data line to either a timer-capture pin on a
> counter-timer chip which captures timestamps for the
> transitions, or you hook it to an input port pin and do the
> timing in software.
>
> > using low level access to the UART?
>
> I've never seen a UART that could do it.
>
> --
> Grant Edwards grante Yow! Am I in GRADUATE
> at SCHOOL yet?
> visi.com
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: why a separate process for each thread on Linux
Date: Wed, 09 May 2001 19:28:59 GMT
Alexander Viro wrote:
> In article <[EMAIL PROTECTED]>,
> Eric Taylor <[EMAIL PROTECTED]> wrote:
>
> >I see there is a way to share pids? Is that still un-implemented or
> >have things changed?
>
> Hell knows. What for? To emulated Solaris idiocy?
I was wondering what was intended by that feature and whether
any further progress had been made.
No matter how idiotic Solaris might be, it is worthwhile to be
able to have their programs port to linux w/o having to change
source code.
>
>
> >A couple of other questions/issues between a system that has
> >specific threads and linux:
>
> >1. scheduling can be diferent. The threads might share the timeslice
> >of the single process they are working for, Does linux do anything
> >about this esp. on a uniprocessor?
>
> Again, what for? There are ways to set priority. nice(2), for one thing.
> Why reinvent the wheel? If you share VM with previous task schedule()
> is more likely to pick you.
Let's see, that sounds like: "Why would anyone ever want to do that?"
Ah, yes, reminds me of the old Decus sessions. The Dec O.S. guys
would ask that 10 times a day. I once heard a tired developer respond
to a what if question: "Well!! What if I fly off this stage!"
The last thing a programmer should ask is What For? Unless he wears
a big G on his shirt.
Let's see, maybe I don't want to write my own scheduler, but also don't
want my 50 compute threads to act like 50 processes and take over
the system.
>
>
> >2. Exiting or killing the process should kill all the threads, won't
> >linux leave the cloned processes running?
>
> Again, why? _If_ you want that behaviour - do it yourself. Signals
> had been there since times immemorial and it's perfectly doable
> in userland. It's a policy decision and thus userland is where it
> belongs.
So, do you bother to deallocate all memory on exit, or do you
chase down all open i/o channels, or do you simply exit. why
why why. I wouldn't be asking if there were no reason. And
just becuase one can solve the problem writing code doesn't
mean it's good to be forced to write code.
>
>
> >3. do clones share stacks? do they get fixed sizes or can they
> >grow like a process?
>
> Not necessary and it depends on the mmap() flags used to create a
> stack for child.
Suppose I have a program that has a local array (on the stack) and
I want to send a pointer to it to one or more of my threads. Will
that work with clone? And even if you think that is stupid, suppose
I have to port a program that does it and I don't have time to modify it.
>
>
> Process is a collection of resources. VM is one of them. Processes can
> have some resources in common. Why bother with LWPs when context switch
> between the normal processes that share VM is equally cheap?
So you can easily port code. Clone is a great system call, but I can't use
it since it is not portable. There are still other systems in the world I have
to be aware of.
------------------------------
From: "Norman Black" <[EMAIL PROTECTED]>
Subject: Re: cache coherency, threads, SMP
Date: Wed, 9 May 2001 12:59:33 -0700
Reply-To: "Norman Black" <[EMAIL PROTECTED]>
What the P6 architecture does is bus snooping. When a processor places an
address on the bus for a read others processors snoop this and if their
cache contains an updated value that process will drive the data onto the
bus and not the memory controller. IF the address pushed on the bus is for a
write other processors invalidate that memory location within their cache.
The processor caches all operate on a cache line. Therefore a one byte write
to memory from one processor invalidates an entire cache line in other
processors caches.
The cache line has been 32-bytes since the Pentium. The cache line is 4
times the width of the processor data bus, which is 64-bits. Cache lines
begin on addresses modulo 32.
Therefore if you have spinlock variables it is best if the lock variable not
exist in the same cache line as other data used by various threads.
Actually any data that two or more threads will be simultaneously accessing
should be in unique cache lines so that multiple processors do thump each
others caches.
--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom
"D. Stimits" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Rik van Riel wrote:
> >
> > D. Stimits wrote:
> >
> > > In an effort to write more efficient threaded code (x86), and
> > > considering cache thrashing, I'm interested in finding out
> > > more about the cache coherency scheme used in 2.2 and 2.4
> > > kernels. Is it a simple write-invalidate scheme?
> >
> > > On a minor note, I'm curious how closely linux x86 SMP cache
> > > schemes are to other x86 UNIX style systems?
> >
> > Cache coherency between different CPUs is completely done in
> > hardware (on x86). This means Linux and other Unices will be
> > using the same cache coherency scheme ;)
>
> 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?
>
> >
> > Btw, this is happening no a per-cacheline basis, using the MESI
> > protocol between CPUs.
>
> To improve performance, it would still be nice to know the exact size of
> a cache line in order to keep two areas of global data from splitting up
> ownership of a given cache line. Are all x86 cpu's using the same size
> cache line? Is this 32 bytes, or some other known size (and if not is
> there a way to find out through hardware detection)?
>
> D. Stimits, [EMAIL PROTECTED]
>
> >
> > --
> > Rik
> > --
> > Virtual memory is like a game you can't win;
> > However, without VM there's truly nothing to lose...
> >
> > http://www.surriel.com/ http://distro.conectiva.com/
> >
> > Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
------------------------------
From: "Sujeet Kharkar" <[EMAIL PROTECTED]>
Subject: Guid generator for unix.
Date: Wed, 9 May 2001 13:03:26 -0700
Do any one knows of any utility for unix which is equivalent of guidgen on
windows ?
Thanks
Sujeet
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: why a separate process for each thread on Linux
Date: 9 May 2001 16:19:00 -0400
In article <[EMAIL PROTECTED]>,
Eric Taylor <[EMAIL PROTECTED]> wrote:
>
>Alexander Viro wrote:
>
>> In article <[EMAIL PROTECTED]>,
>> Eric Taylor <[EMAIL PROTECTED]> wrote:
>>
>> >I see there is a way to share pids? Is that still un-implemented or
>> >have things changed?
>>
>> Hell knows. What for? To emulated Solaris idiocy?
>
>I was wondering what was intended by that feature and whether
>any further progress had been made.
>
>No matter how idiotic Solaris might be, it is worthwhile to be
>able to have their programs port to linux w/o having to change
>source code.
_If_ it doesn't mean putting extra cruft into the kernel. Otherwise you'd
have to copy every idiotic feature ever invented. Not a good idea.
>Let's see, maybe I don't want to write my own scheduler, but also don't
>want my 50 compute threads to act like 50 processes and take over
>the system.
Lower their priority and be done with that. Same effect, no new API needed.
>So, do you bother to deallocate all memory on exit, or do you
>chase down all open i/o channels, or do you simply exit. why
>why why. I wouldn't be asking if there were no reason. And
>just becuase one can solve the problem writing code doesn't
>mean it's good to be forced to write code.
Deallocating memory and closing files avoids kernel leaks. It _can't_
be reliably done in userland. Delivering signals to processes you want
is doable there. Moreover, _not_ doing that is a valid decision and
such decision belongs to userland.
>> >3. do clones share stacks? do they get fixed sizes or can they
>> >grow like a process?
>>
>> Not necessary and it depends on the mmap() flags used to create a
>> stack for child.
>
>Suppose I have a program that has a local array (on the stack) and
>I want to send a pointer to it to one or more of my threads. Will
>that work with clone? And even if you think that is stupid, suppose
>I have to port a program that does it and I don't have time to modify it.
If these clones share VM - sure, it will (they may have separate VM,
but shared file descriptors - combination that also makes sense and
again, that's a decision belonging to userland).
>> Process is a collection of resources. VM is one of them. Processes can
>> have some resources in common. Why bother with LWPs when context switch
>> between the normal processes that share VM is equally cheap?
>
>So you can easily port code. Clone is a great system call, but I can't use
>it since it is not portable. There are still other systems in the world I have
>to be aware of.
Let's see. By that logics we would have to implement
* streams (every Missed'em'V out there)
* doors (Solaris)
* environment-dependent symlinks (dual-universe monsters)
* mpx (remember that v7 misfeature?)
* /dev/poll (SGI barfball)
* several mutually incompatible variants of devfs
* logicals (Vomit Making System)
* drive letters (DEC-derived systems, including CP/M branch)
* AST (VMS)
I can easily continue, but I think you already see what I mean.
BTW, I would like to see Solaris supporting notes, clean userland filesystems,
per-process namespaces and _both_ rfork() a-la BSD (== clone() in Linux) and
rfork() a-la Plan 9 (stack is always private). You see, there's a bunch of
very nice programs that rely on them and I'd love to see them on Solaris.
Yes, some of them are ported, but it would be nice to have all this stuff
natively. Call me when it happens, OK?
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
Subject: Re: Guid generator for unix.
From: [EMAIL PROTECTED]
Date: 09 May 2001 16:27:51 -0500
>>>>> "SK" == Sujeet Kharkar <[EMAIL PROTECTED]> writes:
SK> Do any one knows of any utility for unix which is equivalent of
SK> guidgen on windows ?
uuidgen
It is a part of the e2fsprogs package on your linux distro (on debian
that package is e2fsprogs).
--
Salman Ahmed
To reply, remove "nospam." from my email address
ssahmed AT pathcom DOT com
------------------------------
From: Chronos Tachyon <[EMAIL PROTECTED]>
Subject: Re: Guid generator for unix.
Date: Wed, 09 May 2001 20:28:47 GMT
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 ?
>
> Thanks
> Sujeet
>
>
>
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 ---
--
Chronos Tachyon
Guardian of Eristic Paraphernalia
Gatekeeper of the Region of Thud
[Reply instructions: My real domain is "echo <address> | cut -d. -f6,7"]
------------------------------
Subject: Re: Checking if a pointer is valid
From: [EMAIL PROTECTED]
Date: 09 May 2001 17:05:31 -0500
>>>>> "Florian" == Florian Gro�e-Coosmann <[EMAIL PROTECTED]> writes:
Florian> Try to parse /proc/<getpid()>/maps, have a look at "man 5
Florian> proc".
How would you make such functions thread-aware and thread-safe ?
The approach that you describe above should already be thread-aware
since threads under Linux are separate processes, right ?
--
Salman Ahmed
To reply, remove "nospam." from my email address
ssahmed AT pathcom DOT com
------------------------------
Subject: InterlockedIncrement(), InterlockedDecrement() ?
From: [EMAIL PROTECTED]
Date: 09 May 2001 17:06:21 -0500
Are there any equivalents of the Windows functions
InterlockedIncrement() and InterlockedDecrement, under Linux ?
Thanks.
--
Salman Ahmed
To reply, remove "nospam." from my email address
ssahmed AT pathcom DOT com
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: why a separate process for each thread on Linux
Date: Wed, 09 May 2001 21:21:46 GMT
In article <9dbr91$[EMAIL PROTECTED]>, 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.
[-]
Given clone(2) is Linux specific clone(2) does not exist, you've never
heard of clone(2), you know of no-one who'd ever heard of clone(2)
and Montezuma's revenge shall come over you the day you dare to think
of how nice a clone(2) system call would be.
You get the idea ;)
Ta',
Juergen
--
\ Real name : Juergen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
Subject: Re: why a separate process for each thread on Linux
From: Dragan Cvetkovic <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: 09 May 2001 17:39:59 -0400
[EMAIL PROTECTED] (Alexander Viro) writes:
[snip]
> Let's see. By that logics we would have to implement
[snip]
> * /dev/poll (SGI barfball)
[snip]
Just out of curiosity, what's wrong with /dev/poll (on Solaris)? Reading
man page poll(7d), it looks very promising for fast poll over on many file
descriptors.
Thanks, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole
------------------------------
Subject: shared DLLs written in C++, and _init(), _fini()
From: [EMAIL PROTECTED]
Date: 09 May 2001 17:51:30 -0500
I am writing a few shared, dynamic libraries (DLLs) that will be used by
another program using the dlopen()/dlsym() calls.
The shared DLLs are being written in C++, and what I am trying to do is
to have some initialization code put into the _init() method that gets
called when the DLL is loaded via dlopen(), and some cleanup code put
into _fini() when the DLL is unloaded via dlclose().
The problem is that whenever I add the _init() and _fini() methods to
my DLL's C++ source file that contains the symbols that will be accessed
via dlsym(), I get the following link error:
ModuleMain.o: In function `__malloc_alloc_template<0>::deallocate(void *, unsigned
int)':
/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_alloc.h(.text+0x0):
multiple definition of `_init'
/usr/lib/crti.o(.init+0x0): first defined here
/usr/bin/ld: cannot find -ldlo
collect2: ld returned 1 exit status
make: *** [libFilter1.so] Error 1
So it seems that _init() is already defined in the libc6 runtime.
Now, if I compile my DLL passing the "-nostdlib" flag to g++ at link
time, I don't get this problem and DLL's source file containing _init()
and _fini() is linked in without any apparent problems.
But what happens then is that any static/global objects defined in my
DLL aren't initialized! It seems that the C++ runtime's static
object initializer function isn't called.
Is there any way to have the _init() and _fini() methods in my shared
DLL object that is written in C++ ?
I am using:
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20010506 (Debian prerelease)
on a Debian sid/unstable system:
Linux matrix 2.4.4 #1 Mon Apr 30 11:33:37 EST 2001 i686 unknown
Thanks for any info.
--
Salman Ahmed
To reply, remove "nospam." from my email address
ssahmed AT pathcom DOT com
------------------------------
** 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
******************************
