Linux-Development-Sys Digest #706, Volume #8 Wed, 9 May 01 15:13:15 EDT
Contents:
Re: why a separate process for each thread on Linux (Alexander Viro)
Re: background process survive session close? (Eric Taylor)
Re: why a separate process for each thread on Linux (Eric Taylor)
Linux, laptops and sound ("Odin")
Re: STLport 4.0 & g++ 2.96 (David Konerding)
5th Annual Linux Showcase & Conference: Call for Papers (Tiffany Peoples)
Re: why a separate process for each thread on Linux (Alexander Viro)
Re: getting - failed ioctl
Re: getting - failed ioctl (Alexander Viro)
Re: wait() and lost children ([EMAIL PROTECTED])
Re: why a separate process for each thread on Linux ([EMAIL PROTECTED])
Re: why a separate process for each thread on Linux ([EMAIL PROTECTED])
Re: user memory locked down to kernel pages? ("Norm Dresner")
Re: What does the _REENTRANT symbol enable ? ("Norm Dresner")
Re: why a separate process for each thread on Linux (Alexander Viro)
Re: why a separate process for each thread on Linux (Greg Copeland)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: why a separate process for each thread on Linux
Date: 9 May 2001 12:29:21 -0400
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.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: background process survive session close?
Date: Wed, 09 May 2001 16:44:01 GMT
Thanks for the nohup....
If I run a command that is a pipeline, do I need the nohup in
each section, i.e.
nohup prog1 | nohup prog2 &
or is there a way to do this with a single nohup?
And any guesses as to why sometimes a background process gets
left running when I close the session - but not always? Is this a bug?
thanks
eric
Lew Pitcher wrote:
> On Wed, 09 May 2001 15:53:43 GMT, Eric Taylor <[EMAIL PROTECTED]>
> wrote:
>
> >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.
>
> The process ignores the SIGHUP signal.
>
> To get this from the commandline:
> nohup program ... &
>
> >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
> >
> >
>
> Lew Pitcher, Information Technology Consultant, Toronto Dominion Bank Financial Group
> ([EMAIL PROTECTED])
>
> (Opinions expressed are my own, not my employer's.)
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: why a separate process for each thread on Linux
Date: Wed, 09 May 2001 17:06:43 GMT
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.
>
I see there is a way to share pids? Is that still un-implemented or
have things changed?
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?
2. Exiting or killing the process should kill all the threads, won't
linux leave the cloned processes running?
3. do clones share stacks? do they get fixed sizes or can they
grow like a process?
4. where do the signals go?
et
>
> --
> "You're one of those condescending Unix computer users!"
> "Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: "Odin" <[EMAIL PROTECTED]>
Subject: Linux, laptops and sound
Date: Wed, 9 May 2001 19:08:03 +0200
Hello,
First: Sorry for posting in this group, but this is the only
reasonable linux newsgrp who might be able to help me...
I'm currently running Mandrake 8, and can't seem to get my sound card to
work properly. Here's my prob:
Targa Xtender 300 (OEM manufacturer...?!?)
PIII 850
128MB ram
ATI 4MB AGP Mobility
Ensoniq Ess1371
DVD
(I have no external volume controller... To set the volume in windows,
I must use Creative drivers...)
- Modules are inserted into the kernel correctly (with 2.4 kernel it says
failed during boot, but they are inserted...) lsmod shows the correct
modules.
- I can play sound, but have to connect external speakers to the headphone
out and crank the volume up real high. The mixer settings are at max too.
(The internal speakers are always silent even if I dont connect external
speakers.)
I have no external volume controll on my laptop...
This is controlled with software in Windows (everything works here..duh).
- The card is correctly identified with 2.2 kernels but not in 2.4 (I think
this is purly cosmetic, as both kernel versions display the same
behaviour.)
Eg. in the mixer the soundcard is identified as unknown with 2.4 and
Ess1371 with 2.2
I've been speculating that my soundcard is "sleeping" (power saving or
something) until Windows wakes it up (eg. plug-and-pray) during boot. Maybe
linux is
unable to do this?
I've tried compiling / recompiling with module and kernelsupport for this
soundcard.Also tried ALSA drivers... No luck...
To sum up: How do I activate my internal laptop speakers? Or how do I
redirect
the sound output from head-phones out to the internal speaker?
Any suggestions?
Thanks!
------------------------------
From: [EMAIL PROTECTED] (David Konerding)
Subject: Re: STLport 4.0 & g++ 2.96
Date: 9 May 2001 17:05:23 GMT
Reply-To: [EMAIL PROTECTED]
On 9 May 2001 11:14:19 +0100, Philip Armstrong <[EMAIL PROTECTED]> wrote:
> In article <9dasv6$re2$[EMAIL PROTECTED]>,
> Philip Armstrong <[EMAIL PROTECTED]> wrote:
>>gcc -nostdinc -I/usr/local/include -L/usr/local/lib -nodefaultlibs -lc
>>
>>probably (I haven't tried the above).
>>
>>The gcc documentation isn't *that* hard to read is it?
>
> hmm. I probably meant
>
> g++ -nostdinc -I/usr/include -I/usr/local/include -L/usr/lib \
> -L/usr/local/lib -nodefaultlibs -lc -lstdc++
>
> naturally I haven't tried this either (in true usenet fashion...)
>
> note that you *probably* actually want something like
> -I/usr/local/include/STLPort/ (or wherever the STLPort includes
> are...) rather than just -I/usr/local/include, and likewise for the
> library paths.
The way to do it is:
g++ -I<path_to_STLport>/stlport -c code.cpp -o code.o
gcc -L<path_to_STLport>/lib -o code code.o -lstlport_gcc
You don't need to use -nostdinc++ when you compile (because
the -I/<path_to_STLport>/stlport comes before the system search
path).
You don't want to link using g++ because that links with libstdc++,
and you don't want that if you're linking against STLport-- it's
redundant, although possibly harmless.
Dave
------------------------------
From: Tiffany Peoples <[EMAIL PROTECTED]>
Subject: 5th Annual Linux Showcase & Conference: Call for Papers
Date: Wed, 09 May 2001 10:37:49 -0700
5th Annual Linux Showcase & Conference (ALS 2001)
November 6-10, 2001
Oakland, CA USA
http://www.linuxshowcase.org
Sponsored by USENIX and the Atlanta Linux Showcase, Inc., in cooperation
with Linux International
Now in its fifth year, the Annual Linux Showcase & Conference
http://www.linuxshowcase.org continues its remarkable development as the
premier technical Linux conference, attracting talks by experts on
everything from kernel internals to Internet services, panels discussing
the state of the Kernel, Linux in the real world, xfree86, and more.
And this year, ALS breaks with tradition by moving out of Atlanta to the
SF Bay Area!
The ALS 2001 Program Committee invites you to contribute your ideas,
proposals, and papers for tutorials, invited talks, refereed technical
papers, and work-in-progress reports. We welcome submissions that
address any and all issues relating to Linux and the Open Source world.
The Call for Papers with submission guidelines and suggested topics is
now available at http://www.linuxshowcase.org
Submissions are due June 5, 2001
The first XFree86 Technical Conference will run concurrently with ALS on
November 7 & 8. If you are a developer building applications and systems
using XFree86, plan to submit a paper or attend this event. For more
information check: http://www.usenix.org/events/xfree86/
Please join us and participate in the premier technical conference for
Linux enthusiasts and professionals! We look forward to seeing you in
Oakland in November 2001!
===============================================================
5th Annual Linux Showcase & Conference (ALS 2001) is sponsored by
USENIX, the Advanced Computing Systems Association, and the Atlanta
Linux Showcase, in cooperation with Linux International.
===============================================================
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: why a separate process for each thread on Linux
Date: 9 May 2001 13:36:19 -0400
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?
>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.
>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.
>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.
>4. where do the signals go?
Where you send them. Why?
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?
Occam's Razor and all such... BTW, it's not like the thing was invented in
Linux - it comes from Plan 9 and is shared with *BSD (man rfork there).
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: getting - failed ioctl
Date: Wed, 09 May 2001 17:39:22 -0000
In article <[EMAIL PROTECTED]>,
Michael Ferguson <[EMAIL PROTECTED]> wrote:
>
>These fops must have the address of the function not just the name,
>
>ie.
>
>...
>NULL,
>&plx_ioctl,
>NULL,
>&plx_open,
>NULL,
Huh?
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: getting - failed ioctl
Date: 9 May 2001 13:44:02 -0400
In article <[EMAIL PROTECTED]>,
Michael Ferguson <[EMAIL PROTECTED]> wrote:
>
>These fops must have the address of the function not just the name,
>
>ie.
>
>...
>NULL,
>&plx_ioctl,
>NULL,
>&plx_open,
>NULL,
Learning C is a good idea - might even help you to avoid looking like an
idiot when you give advices on it...
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: wait() and lost children
Date: 9 May 2001 17:54:18 GMT
On 09 May 2001 10:39:41 -0500 Greg Copeland <[EMAIL PROTECTED]> wrote:
| Have you tried writing a simple test program which tests this. Wouldn't
| be hard. Just loop on a fork. Have the child sleep while the parent
| wait()s. Once you've waited on the same number of children that you
| forked, you're done. If you only get a single wait that ever completes,
| please post the code or email it to me and let's make sure it's not
| a coding issue. If it's not a coding issue, then it sounds like it
| might be a serious kernel issue. Oh ya, don't forget to have your
| children _exit() when they are done with their nap.
|
| Honestly, since this type of implementation is used all of the time
| in UNIX style applications, I have a hard time believing that the
| kernel is at fault here. But, you never now... ;)
I've written this kind of server before, and haven't had problems.
But then it wasn't being hit by crazy people wielding strange mail
clients. I just hate to put a lot of time into this program, as
there are other POP3 servers around. I might be better off just
dropping this one and finding another.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: why a separate process for each thread on Linux
Date: 9 May 2001 18:07:02 GMT
On 09 May 2001 10:26:09 -0500 Greg Copeland <[EMAIL PROTECTED]> wrote:
| I see this example used all of the time when people want to frown on
| threaded programming. I for one, don't buy it. I've coded lots of
| multi-threaded applications and have never once had this as an issue
| like this. Let's face it, it's not hard to serialize something like
| this. Once you have a file handle to the file in question, it's not
| like you have to keep chdir()ing every time you turn around.
|
| I've never once needed to write an application that created two
| threads which did nothing but change directories in each thread.
| Besides, normally, you'll be better served having a select few
| thread(s) taking care of this type of detail for you. Even still,
| there are lots of others way to crack this nut.
|
| In a nutshell, threaded programming is just another model which may
| or may not apply to the specific problem domain you are trying to
| address. It's nothing more, or less. Just another tool in the shed.
I've written library code that could fail if it depended on being
able to access a file via a full path. It really needed to do a
chdir() to accomplish what it needed to do. The concern with it
was that if someone used this in a threaded program, and some other
thread simply did a file open in what what it thought was the current
directory, it could be in for a rude surprise.
I've been doing multi process programming since getting into UNIX.
The cases I've worked with have been in more need of seperate
resources than in shared memory. So they would fit the process
model better. And it didn't require another API. I've also done
multi task (similar to multi threaded) on mainframes (MVS). So
I guess this colors my view of things. I'll just have to see when
my first case of needing multi-threading comes about.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: why a separate process for each thread on Linux
Date: 9 May 2001 18:16:44 GMT
On Wed, 09 May 2001 17:06:43 GMT Eric Taylor <[EMAIL PROTECTED]> wrote:
| I see there is a way to share pids? Is that still un-implemented or
| have things changed?
Based on what I read it is implemented, but causes "problems" since
other parts of the kernel think all processes have unique PID. For
example, the /proc/NNNN entries are likely to be usless. There needs
to be some way to identify each thread beyond a thread entry pointer.
Maybe a PID:TID tuple? But a lot of stuff would have to change to
handle that.
| 2. Exiting or killing the process should kill all the threads, won't
| linux leave the cloned processes running?
I know this principle is used, but I'm not sure sure it's the right
way. But then, I'm probably clouded in thought by having had only
projects that need the process model, as opposed to the thread model.
| 3. do clones share stacks? do they get fixed sizes or can they
| grow like a process?
That can't be allowed to avoid corruption. If you're sharing the
whole VM, then each thread has to have its own stack context. And
with stacks that grow linearly, you have to pick starting points
and divvy up the VM space by picking a suitable stack size. If the
stack is made truly separate, then you have other issues, like
threads can share some pointers (gotten from malloc()) but not
others (gotten from auto variables or alloca() ... but then I'd
bet alloca() is thread-unsafe anyway).
| 4. where do the signals go?
I guess they are a pushed context in the same process/thread.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Re: user memory locked down to kernel pages?
Date: Wed, 09 May 2001 18:58:05 GMT
Ralf Render <[EMAIL PROTECTED]> wrote in message
news:9dapee$aar$[EMAIL PROTECTED]...
> Thanks for your help, Arne.
> But I can not change my intention.
> Each time the user requests a transfer he informs the driver about the
> target address.
> To avoid copying the whole memory from kernel to user memory I want the
bus
> muster dma to transfer directly to the user target memory.
> If I map kernel memory the user has to copy the data before starting the
> next transfer.
> After that he can work with the copy.
> Both solutions waste too much time in copying huge amount of data.
>
> Ralf.
>
>
> "Arne Driescher" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
> news:[EMAIL PROTECTED]...
> >
> >
> > Ralf Render wrote:
> > >
> > > Hi all,
> > >
> > > does anybody know, whether in one of the latest kernels it is possible
> > > to lock down user memory to kernel pages?
> > > My kernel driver needs to lock given user memory by preventing it form
> > > beeing swapped.
> > > I want to use the pages of this memory for a busmaster DMA of my
> > > PCI-Card to transfer data directly from PCI memory to user memory.
> > > After doing that the user memory should be unlocked.
> > > Thanks for help.
> > >
> > > Ralf.
> >
> > You should rethink your approach. A driver should allocate
> > the memory by itself and provide it to the application via mmap.
> > This gives you painless access to the phys. addr. of the
> > pages and driver memory will never be swaped out.
> >
> > -Arne
>
You can reserve a section of RAM at the top of memory (i.e. keep Linux from
using it) by adding a command to the lilo "command line". Once this memory
is reserved, it can be accessed by both user and kernel using mmap() and
ioremap() and this memory is frozen in place.
For example if I have 64 MB of RAM, I could add to the lilo.conf
append="mem=62m "
which would reserve the top 2 MB of RAM. There are supposed to be ways to
do this if you don't use lilo but I haven't investigated them.
------------------------------
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Re: What does the _REENTRANT symbol enable ?
Date: Wed, 09 May 2001 19:01:17 GMT
Juergen Heinzl <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> >
> >I was reading in John Goerzen's "Linux Programming Bible" that shared,
> >dynamic libraries should be built with the _REENTRANT symbols defined
> >for all source files that are compiled into it.
> >
> >What exactly does the _REENTRANT symbol enable in the system (ie libc)
> >headers and elsewhere ?
> [-]
> I'm only aware of errno and h_errno becoming functions behind your
> back since their values must be thread specific. Mind even a single
> threaded application has one thread at least. It'd help at least to
> make libraries useable with both, MT and non MT apps.
>
> Still one is free to use functions like fputs_unlocked() for speed
> reasons, but sure, in such cases the programmer had better aware what
> he or she is doing, or might use other functions like gethostbyname()
> which are not thread safe and so "import" non-threadsafe functions
> behine ones back. In short, I'm not sure about how useful it really is.
>
> I don't know the book mentioned btw, so take all this with a grain
> of salt.
>
> Ta',
> Juergen
One of the requirements in creating a reentrant function is that it
maintain absolutely no static memory, i.e. that all memory be ether from
function parameters or on the stack.
Perhaps for some compilers this forces creating all temporary storage on the
stack, i.e. no implicit static data areas.
Norm
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: why a separate process for each thread on Linux
Date: 9 May 2001 15:02:32 -0400
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>| 3. do clones share stacks? do they get fixed sizes or can they
>| grow like a process?
>
>That can't be allowed to avoid corruption. If you're sharing the
That _can_ be allowed if parent and child cooperate. Not for long,
but it's doable. All you need is to block parent until the child
will tell that it's OK. Or block child and let parent flip the
child's stack via ptrace(). See vfork() for example of the first
approach, BTW.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
Subject: Re: why a separate process for each thread on Linux
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 09 May 2001 14:08:15 -0500
[EMAIL PROTECTED] writes:
> On Wed, 09 May 2001 17:06:43 GMT Eric Taylor <[EMAIL PROTECTED]> wrote:
>
> | I see there is a way to share pids? Is that still un-implemented or
> | have things changed?
>
> Based on what I read it is implemented, but causes "problems" since
> other parts of the kernel think all processes have unique PID. For
> example, the /proc/NNNN entries are likely to be usless. There needs
> to be some way to identify each thread beyond a thread entry pointer.
> Maybe a PID:TID tuple? But a lot of stuff would have to change to
> handle that.
Hey, this is the Phil that I know. I use your linuxhomepage still.
I like it.
For what it's worth, I do know that some thought it going into
additional thread support in the Linux kernel. I just don't know
what form it will take yet.
--
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
==================================================
------------------------------
** 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
******************************
