Linux-Development-Sys Digest #92, Volume #8 Mon, 21 Aug 00 21:13:20 EDT
Contents:
Re: all threads in a process share the same pid? (Kevin Lacquement)
Kernel upgrade confusion: lilo/loadlin (Lawrence)
Re: Camera Application software run on Linux PC (bill davidsen)
Re: all threads in a process share the same pid? (Kaz Kylheku)
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
Re: all threads in a process share the same pid? (Kaz Kylheku)
modules char-major-6? ([EMAIL PROTECTED])
Re: all threads in a process share the same pid? (Kaz Kylheku)
Re: all threads in a process share the same pid? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Kevin Lacquement <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Date: Mon, 21 Aug 2000 21:29:34 GMT
[EMAIL PROTECTED] wrote:
>
> In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>
> > The Linux kernel gives you a choice; you can do a clone without
> > CLONE_FS to give each thread its own root and cwd. It makes sense
> > for a thread to be able to chdir() independently without affecting
> > other threads.
>
> This is wholey a matter of opinion. I mine, it makes much more sense
> for threads to share the current working directory. In particluar, if
> you call chdir() based on user input in one thread, the logical
> assumption is that the user wanted to change his working directory,
> not that he wanted to change it "just for this thread"
>
I can see a use for this. Consider a multi-window X app, where, to the
user's view, each window is completely separate. In this case, the user
may wish to chdir() in one window, while leaving another window in the
old directory. Now, suppose that each window is actually controlled by
a separate thread from a single process.
I admit that you could store the directory info with each window, and
chdir() each time you change windows - unless the app is asynchronous.
Consider that something running in the background in window 'A' needs to
work with a directory, so it chdir()s there. Now, in window 'B', the
user is opening a file. So the app chdir()s to window B's working
directory, unfortunately changeing window 'A' at the same time. What
does the user see? Possibly nothing...until s/he tries to use the files
from window 'B's directory again, and they've been changed by the thread
in window 'A'.
Cheers,
Kevin
------------------------------
From: Lawrence <[EMAIL PROTECTED]>
Subject: Kernel upgrade confusion: lilo/loadlin
Date: Mon, 21 Aug 2000 21:29:29 GMT
Hi everyone,
newbie here. First of all, I think the site I'm using is forcing the post
to a developpement group; sorry in advance if my newbie question ends up
in an advanced group.
That said, I'm using loadlin to boot Red Hat 6.0 (works fine) and I want
to upgrade my distribution and/or kernel eventually. Faqs and howtos give
tips for updating lilo configuration. I don't know anything about lilo
yet; not even whether I'm using it implicitely or not. So in my case
(loadlin), what would I have to do differently to make a new kernel boot
and work properly?
Thanks in advance,
-Lawrence
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.networking,comp.os.linux.setup
Subject: Re: Camera Application software run on Linux PC
Date: 21 Aug 2000 22:02:31 GMT
In article <8msmmb$qrt$[EMAIL PROTECTED]>,
bill davidsen <[EMAIL PROTECTED]> wrote:
| Is the hardware still available? I have several webcams which I
| ordered only to find that the model had changed, and by the time there
| was Linux support the camera was out of production.
And to answer my own question, no.
Since being able to capture pictures is a solid requirement, and none
of the dozen or so packages for Linux seem to work with a camera which
is still made, I guess MS wins. I can't tell someone to base their
business plan on buying used stuff from eBay.
Thanks for the info, lots of these packages should work for personal
use if you can find the camera at a garage sale near you.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
Make the rules? I don't make the rules. I don't even FOLLOW the rules!
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 21 Aug 2000 22:16:08 GMT
On Mon, 21 Aug 2000 20:10:28 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>> Also consider that the chdir() system call is needed in avoiding
>> limitations on the length of a pathname that can be passed in a
>> single file-related system call.
>
>This is completely wrong. There shouldn't be _any_ case in which
>chdir() will accept a pathname longer than open() or close().
That's tno the issue. You can make several calls to chdir in order to shorten
the relative path needed to access an object that is inaccessible via an
absolute path. POSIX provides no thread-safe way of doing this. All code that
wants to chdir has to agree with all other code on some locking mechanism.
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
From: [EMAIL PROTECTED]
Date: Mon, 21 Aug 2000 22:57:34 GMT
[EMAIL PROTECTED] writes:
> This is wholey a matter of opinion. I mine, it makes much more sense
> for threads to share the current working directory.
What about a multithreaded file manager, where each window may
represent a different directory? When the user double-clicks on a
program, the program should have the directory of the window as its
current directory (even if the "program" is really just a symlink to a
program in a different directory). If the kernel doesn't allow
different current directories for each thread, before fork/exec you
have to lock the current directory using a mutex (to keep the same
user from opening another program in a different directory and thus
screwing both up), change directories, fork/exec, return to the
original directory (unless you always use absolute paths), and unlock
the directory.
> In particluar, if you call chdir() based on user input in one
> thread, the logical assumption is that the user wanted to change his
> working directory, not that he wanted to change it "just for this
> thread"
Maybe in some cases. In a lot of programs, though, threads are
treated like lightweight processes with shared memory. I don't
believe this is totally because of the implementation in Linux, as I
saw that attitude in OS/2 (where threads are quite distinct from
processes) and Windows (Explorer is a single process with many threads).
> > Also consider that the chdir() system call is needed in avoiding
> > limitations on the length of a pathname that can be passed in a
> > single file-related system call.
> This is completely wrong. There shouldn't be _any_ case in which
> chdir() will accept a pathname longer than open() or close().
I think he means if you have some path like:
/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z.txt
you can get at z.txt via
chdir("/a/b/c/d/e/f");
chdir("g/h/i/j/k/l/m");
chdir("n/o/p/q/r/s/t");
fopen("u/v/w/x/y/z.txt", "r");
Now, if each of those letters are actually words twenty characters
long...
Let's say you want to open the above file in one thread, while other
threads possibly open files in the cwd. It can't be done. You have
to change directories in pieces, and thus another thread can get a
timeslice in the middle; when it tries to fopen() a file in the cwd,
it will fail. The only solution is to use a mutex to protect chdir,
fopen, and so on.
I think that the cases where this is a problem are going to be few and
far between, but maybe Kaz has some experience to the contrary.
--
Eric McCoy ([EMAIL PROTECTED])
"corsair, n. A politician of the seas."
- Ambrose Bierce, The Devil's Dictionary
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Mon, 21 Aug 2000 23:01:09 GMT
In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> On Mon, 21 Aug 2000 20:10:28 GMT, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>>> Also consider that the chdir() system call is needed in avoiding
>>> limitations on the length of a pathname that can be passed in a
>>> single file-related system call.
>>
>>This is completely wrong. There shouldn't be _any_ case in which
>>chdir() will accept a pathname longer than open() or close().
> That's tno the issue. You can make several calls to chdir in order
> to shorten the relative path needed to access an object that is
> inaccessible via an absolute path. POSIX provides no thread-safe
> way of doing this. All code that wants to chdir has to agree with
> all other code on some locking mechanism.
Why _would_ it? This is completely _not_ a threading issue if you
accept the premise that threads should be different from processes.
As far as inaccessible objects go, that's solvable by serializing
access to your own version of open which does the requisite amount of
chdirs, opens the file, then returns the file descriptor.
It's also worth noting that most likely, anything in this fictious
data store will be inaccesible to any other program which calls open()
without a hoard of chdirs before hand. That is, by just about any
other application.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Mon, 21 Aug 2000 23:22:25 GMT
In comp.os.linux.development.system [EMAIL PROTECTED] wrote:
> Maybe in some cases. In a lot of programs, though, threads are
> treated like lightweight processes with shared memory. I don't
> believe this is totally because of the implementation in Linux, as I
> saw that attitude in OS/2 (where threads are quite distinct from
> processes) and Windows (Explorer is a single process with many threads).
No, it's quite a common model. Certainly not the only one,
however. More to the point, it's certainly not the only valid one.
On top of that, processes are _already_ lightweight enough to solve
any of these shared context problems.
> Let's say you want to open the above file in one thread, while other
> threads possibly open files in the cwd. It can't be done. You have
> to change directories in pieces, and thus another thread can get a
> timeslice in the middle; when it tries to fopen() a file in the cwd,
> it will fail. The only solution is to use a mutex to protect chdir,
> fopen, and so on.
Or, as I said, to use one to protect open_mangled_filename().
> I think that the cases where this is a problem are going to be few and
> far between, but maybe Kaz has some experience to the contrary.
And easily enough solved by using the file descriptor, and not the
path name. I have to agree that this is most likely something the vast
majority of people will never see.
I also should point out that this _single_ dubious "benefit" of
LinuxThreads over Posix threads in no way makes up for the _ten_
incompatabilities I posted before. Until a better argument against the
standard, or a better example of the "technical excellence" of
LinuxThreads comes to light, I'll still prefer pthreads. ;)
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 21 Aug 2000 23:22:54 GMT
On Mon, 21 Aug 2000 23:01:09 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>> On Mon, 21 Aug 2000 20:10:28 GMT, [EMAIL PROTECTED]
>> <[EMAIL PROTECTED]> wrote:
>>>> Also consider that the chdir() system call is needed in avoiding
>>>> limitations on the length of a pathname that can be passed in a
>>>> single file-related system call.
>>>
>>>This is completely wrong. There shouldn't be _any_ case in which
>>>chdir() will accept a pathname longer than open() or close().
>
>> That's tno the issue. You can make several calls to chdir in order
>> to shorten the relative path needed to access an object that is
>> inaccessible via an absolute path. POSIX provides no thread-safe
>> way of doing this. All code that wants to chdir has to agree with
>> all other code on some locking mechanism.
>
>Why _would_ it? This is completely _not_ a threading issue if you
Because you have a potential race condition as soon as some thread does
chdir(); a race against any other thread that is also doing chdir, or
which is using relative paths in calls like open(), stat(), access(),
remove() and so on.
So one solution is to never use chdir() so that you don't break threads that
you don't know about, and never to use relative paths in your own threads, so
that some third party code that calls chdir() won't screw you up.
So in essence, chdir() is not only next to useless in a POSIX MT app, it
can be Considered Harmful (TM).
>accept the premise that threads should be different from processes.
No, it's only not a threading issue if you accept the view that the current
working directory is an attribute of the process rather than of the thread.
There is no reason that this has to be so. There are arguments to do it either
way depending on the requirements at hand, so Linux gives you a choice whether
a new task shares a common CWD with the parent, or whether it has an
independent CWD.
If you have only one choice, then making the CWD a thread attribute is safer,
because it minimizes unwanted interactions between unrelated subsystems; when a
group of related threads need to share a common working directory, it can be
easily arranged. For example, one of the threads can open a file, and then
record the file descriptor into a shared data structure. Then the other threads
can invoke fchdir() on that shared file descriptor.
>As far as inaccessible objects go, that's solvable by serializing
>access to your own version of open which does the requisite amount of
>chdirs, opens the file, then returns the file descriptor.
Now how do you get all the libraries in the system to go to your version of
open, and then access the real open? The overriding of weak symbols is not a
POSIX feature, but rather a platform-specific programming hack. While you are
at it, take care of stat(), access(), chmod() and all the others.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: [EMAIL PROTECTED]
Subject: modules char-major-6?
Date: 21 Aug 2000 21:43:49 GMT
**** Post for FREE via your newsreader at post.usenet.com ****
Hi,
Does any know why I kept getting the error message "modprobe: can't
locate module char-major-6" in my /var/log/message every 5 mintues or
so. I do not remember when it started, but it's quite annoying everytime
I check the log. Please enlighten me if you could..
Thanks in advance
Dan
--
Linux, the choice | Linux, the afterburner for your computer
of a GNU generation -o) |
Kernel 2.2.14 /\ |
on a i586 _\_v |
|
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
http://www.usenet.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 21 Aug 2000 23:34:53 GMT
On Mon, 21 Aug 2000 22:57:34 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>> In particluar, if you call chdir() based on user input in one
>> thread, the logical assumption is that the user wanted to change his
>> working directory, not that he wanted to change it "just for this
>> thread"
>
>Maybe in some cases. In a lot of programs, though, threads are
>treated like lightweight processes with shared memory. I don't
>believe this is totally because of the implementation in Linux, as I
>saw that attitude in OS/2 (where threads are quite distinct from
>processes) and Windows (Explorer is a single process with many threads).
Note that the SetCurrentDirectory() function in Win32 is also process-wide.
I just checked MSDN online. (Could it be that this is where the POSIX guys
have been getting their ideas lately? :)
If Win32 does it, it's usually wrong. QED. :)
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: all threads in a process share the same pid?
Crossposted-To: comp.os.linux.development.apps
Date: Tue, 22 Aug 2000 00:29:19 GMT
In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> No, it's only not a threading issue if you accept the view that the
> current working directory is an attribute of the process rather than
> of the thread. There is no reason that this has to be so. There
> are arguments to do it either way depending on the requirements at
> hand, so Linux gives you a choice whether a new task shares a common
> CWD with the parent, or whether it has an independent CWD.
Well, I can agree with this paragraph in total. ;) I think we'd both
be happy if you could select the behavior. The fact that this is
apparantly already possible with the current kernel makes that a libc
issue, and I'd rather get back to kernel threads. In particular shared
pids, which are _not_ possible to solve in libc.
> If you have only one choice, then making the CWD a thread attribute
> is safer, because it minimizes unwanted interactions between
> unrelated subsystems; when a group of related threads need to share
> a common working directory, it can be easily arranged. For example,
> one of the threads can open a file, and then record the file
> descriptor into a shared data structure. Then the other threads can
> invoke fchdir() on that shared file descriptor.
I would say if you have only _one_ choice, making it shared is safer,
because people wishing the shared behavior can use processes rather
than threads. Where as the reverse is not true. For example, you
_cannot_ get a shared cwd on Linux now, without shipping your own
threading library, AFAIK.
However, as I've said before, I'm willing to concede that it may be
useful to have non shared working directories. (Uncle! Uncle!)
Certainly though, making both an option isn't unreasonable. Especially
since that can be done without a kernel mod.
>>As far as inaccessible objects go, that's solvable by serializing
>>access to your own version of open which does the requisite amount of
>>chdirs, opens the file, then returns the file descriptor.
> Now how do you get all the libraries in the system to go to your
> version of open, and then access the real open? The overriding of
> weak symbols is not a POSIX feature, but rather a platform-specific
> programming hack. While you are at it, take care of stat(),
> access(), chmod() and all the others.
What I was suggesting is that you open them all via your own function,
and avoid using the pathname after that, prefering fstat(), fchmod(),
etc.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
** 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 (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
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
******************************
