Linux-Development-Sys Digest #88, Volume #8 Sat, 19 Aug 00 22:13:12 EDT
Contents:
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? (Kaz Kylheku)
Re: CVS commit problems (Rick Ellis)
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: Can't use both USB printer and Promise Ultra66 at the same time (Jonathan Kamens)
Re: all threads in a process share the same pid? ([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: Sat, 19 Aug 2000 22:09:40 GMT
On Sat, 19 Aug 2000 22:03:56 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>> It means, effectively, that threads cannot use chdir() (and chroot()
>> as well), except at the start of the program to set a global working
>> directory. There is no interface in POSIX to even put a lock on the
>> current working directory so that it can be relied on to be stable
>> over a few system calls.
>
>> Also, in the POSIX model, one cannot have threads running under
>> separate user ID's, so that a multithreaded server could
>> authenticate a user and then perform file accesses using that user's
>> credentials.
>
>These are both actually the same "problem" which is that the standard
>defines _threads_ and not _processes_. Either of these is better
>solved through creating children processes than new threads.
The second one is arguably better solved. (From a security perspective, do you
want some non-root threads romping around the same address space as a root
thread?)
However, making a new process just so I can have an independent chdir() is not
a better solution. The Linux kernel has a far better solution; that of
giving a separate working directory to each task.
Programmers should have an escape hatch enabling them to elect this method,
at the sacrifice of portability.
--
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: Sat, 19 Aug 2000 22:15:45 GMT
In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> The way I look at it, if someone can afford to use a few trivial
> noncompliances as an excuse not to port something to Linux, then
> screw them.
It's hardly trivial. Getting threaded software to work on Linux all
too often requires _algorithmic_ changes, not just a couple two-line
patches. So what you're really saying is "If someone won't write
exclusively for Linux, then screw them."
> The existing implementations are buggy. For example, it recently
> came to light in comp.programming.threads that the Solaris open()
> function screws up under thread cancellation. In Linux, it's a
> direct system call, so it is safe. Some application that cancels
> threads that are blocked in open() will currently work better on
> Linux than Solaris.
So, the reason Linux doesn't have posix threads is that Solaris has
bugs? I don't think we need to explore that issue any further.
By the same token, any threaded application which depends on shared
pids will work better on Solaris than Linux, where it won't work at
all. So what we have here are two examples:
1. A poorly written application which takes the somewhat questionable
approach of cancelling threads blocked in open() may have problems on
either platform.
2. A properly written application which follows the standard will work
on Solaris and not Linux.
> So what else is new? Writing code for multiple UNIXes has
> traditionally been an exercise in #ifdef. :) That is why so much
> freeware uses little test programs to determine what works and what
> doesn't.
Unfortunatly, as I said originally, for a program that uses the
missing features, you have to #ifdef out the entire program and use
something else.
--
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: Sat, 19 Aug 2000 22:29:33 GMT
In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> However, making a new process just so I can have an independent
> chdir() is not a better solution. The Linux kernel has a far better
> solution; that of giving a separate working directory to each task.
> Programmers should have an escape hatch enabling them to elect this method,
> at the sacrifice of portability.
But they _can_ via clone(2)! ;)
What I, and everyone else I know on this side of the pthread fence is
suggesting is:
1. Threads invoked via the pthreads api _should_ conform to POSIX,
including sharing pids.
2. In support of 1, the kernel should provide some notion of threads
vs processes, apart from just one of "tasks." This could be as simple
as giving every task a pid and tid, but it clearly needs to be
something that works within system calls.
3. The clone() interface is fine, except that you can't accomplish
either of the above through it, as it stands now. Leaving it as the
basis of an _alternate_ threading mechanism is fine, since most people
just want existing ports to work.
The point is, most of the arguments against Posix are entirely
subjective. For every example where they don't make sense, there's
another where they do.
--
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: Sat, 19 Aug 2000 22:31:58 GMT
On Sat, 19 Aug 2000 22:15:45 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>
>> The way I look at it, if someone can afford to use a few trivial
>> noncompliances as an excuse not to port something to Linux, then
>> screw them.
>
>It's hardly trivial. Getting threaded software to work on Linux all
>too often requires _algorithmic_ changes, not just a couple two-line
>patches. So what you're really saying is "If someone won't write
>exclusively for Linux, then screw them."
Not at all. dlopen() the reading comprehension lib, call yyparse() again. ;)
>> The existing implementations are buggy. For example, it recently
>> came to light in comp.programming.threads that the Solaris open()
>> function screws up under thread cancellation. In Linux, it's a
>> direct system call, so it is safe. Some application that cancels
>> threads that are blocked in open() will currently work better on
>> Linux than Solaris.
>
>So, the reason Linux doesn't have posix threads is that Solaris has
>bugs? I don't think we need to explore that issue any further.
The point is simply that glibc/linux is not alone in having bugs or
non-compliances in the threading library.
>By the same token, any threaded application which depends on shared
>pids will work better on Solaris than Linux, where it won't work at
>all. So what we have here are two examples:
>
>1. A poorly written application which takes the somewhat questionable
>approach of cancelling threads blocked in open() may have problems on
>either platform.
>
>2. A properly written application which follows the standard will work
A properly written application may call pthread_cancel on a thread that happens
to be calling open(). That does not mean that the application is specifically
relying on cancellation in open, it might be that it just happened. You might
have some thread that calls open() as part of its routine and simply want to
shut down that thread using pthread_cancel. You should not care what the thread
is doing at that time; the library functions should be safe against deferred
cancellation.
>on Solaris and not Linux.
That's great, unfortunately if a good chunk, if indeed not the largest
proportion, of the potential user base for that application is on Linux, can it
afford to stay that way? :)
>> So what else is new? Writing code for multiple UNIXes has
>> traditionally been an exercise in #ifdef. :) That is why so much
>> freeware uses little test programs to determine what works and what
>> doesn't.
>
>Unfortunatly, as I said originally, for a program that uses the
>missing features, you have to #ifdef out the entire program and use
>something else.
That is nonsense. Programmers targetting multiple UNIX-like operating systems
have always had to deal with missing features. It didn't prevent programs from
working on many operating system flavors.
I'm writing this article using the editor Vim, which runs on platforms as
diverse as Amiga and VMS. Don't tell me that there aren't any VMS features that
are missing in the Amiga or vice versa.
If the whole program has to be rewritten, that's indicative that maybe the
program is just a contrived test case to exercise the missing API feature,
rather than a useful application.
--
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] (Rick Ellis)
Subject: Re: CVS commit problems
Date: 19 Aug 2000 22:37:04 GMT
In article <[EMAIL PROTECTED]>,
Kevin Kaichuan He <[EMAIL PROTECTED]> wrote:
>cvs [commit aborted]: cannot commit files as 'root'
>
> Is it saying we cann't check in cvs source files as root ? (the
>repository is in local machine)
Why would you be trying to check in as root?
--
http://www.fnet.net/~ellis/photo/
------------------------------
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: Sat, 19 Aug 2000 22:56:14 GMT
On Sat, 19 Aug 2000 22:29:33 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>
>> However, making a new process just so I can have an independent
>> chdir() is not a better solution. The Linux kernel has a far better
>> solution; that of giving a separate working directory to each task.
>
>> Programmers should have an escape hatch enabling them to elect this method,
>> at the sacrifice of portability.
>
>But they _can_ via clone(2)! ;)
No, because clone() cannot be mixed with pthread programming. Clone threads
cannot safely call into glibc (only into a subset of it). Only threads created
with pthread_create are adorned with the proper dressing which allows them to
have the full library at their disposal.
Consider that even simple putchar() calls pthread_mutex_lock() on an
internal lock within stdout; this will fail if called by a thread that has
no associated thread descriptor. So clone() threads cannot use stdio.
Malloc has locks in it, so that's out. Etc.
The solution would be to allow the clone flags to be passed through via a
non-portable member of pthread_attr_t. (Of course, certain flags would not
work properly, obviously).
>What I, and everyone else I know on this side of the pthread fence is
>suggesting is:
>
>1. Threads invoked via the pthreads api _should_ conform to POSIX,
>including sharing pids.
I believe that sharing pids provides nothing to Linux users or developers other
than compatibility with legacy systems, that it's not easy to do and that the
compatibility can be achieved by avoiding the dependency on the shared pid.
The people who are affected by the issue most are developers who have fairly
recently produced a large, non-trivial application on another platform that is
to be ported to Linux, and which invokes the troublesome parts of the
interface.
It doesn't affect people who consider the Linux interface from the start. It
certainly doesn't affect developers of free software that use Linux as one of
their development platforms.
>2. In support of 1, the kernel should provide some notion of threads
>vs processes, apart from just one of "tasks." This could be as simple
>as giving every task a pid and tid, but it clearly needs to be
>something that works within system calls.
It sounds risky; it's entirely understandable why the kernel developers would
not want to risk destabilizing the kernel for the sake of issues that can be
solved in user space.
--
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: Sun, 20 Aug 2000 00:58:12 GMT
In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> No, because clone() cannot be mixed with pthread programming. Clone
> threads cannot safely call into glibc (only into a subset of
> it). Only threads created with pthread_create are adorned with the
> proper dressing which allows them to have the full library at their
> disposal.
That may be, but you didn't ask for pthreads. What you want is a
non-standard threading system that maintains a different working
directory for every thread. On top of that, you said you were willing
to sacrifice portability in order to have it. That can be fulfilled
either with:
1. A new api, which gives you the current, mangled threads.
2. A non-standard extension which makes them behave the current way,
instead of the posix flavor.
In any case, complaining that posix and other threads don't play well
together is a bit of a non-starter. ;)
> The solution would be to allow the clone flags to be passed through via a
> non-portable member of pthread_attr_t. (Of course, certain flags would not
> work properly, obviously).
I agree. If anything, people should be able to choose which thread
model they want.
> I believe that sharing pids provides nothing to Linux users or
> developers other than compatibility with legacy systems, that it's
> not easy to do and that the compatibility can be achieved by
> avoiding the dependency on the shared pid.
I could just as well say that LinuxThreads provides the developers
with nothing that couldn't be done with fork() and shared memory. For
the sake of constructive discussion though, let's consider
http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=552966193&fmt=text which
lists a long list of problems, most of which stem from the shared pid
problem. (Reprinted here to save people following the link)
1) It doesn't handle signals 100% correctly.
2) 'ps' shows every thread in a process.
3) core dumps of multi-threaded codes don't contain all
the threads (or even the crashing one !)
4) getpid() doesn't return the same value for all threads
in a single process,
5) A child process fork()ed in one thread often cannot be
wait()ed for by a different thread, depending upon the
exact parent-child relationships between threads.
6) Threads *have* parent-child relationships (when they
should properly all be peers).
7) uid/gid information isn't common to all threads in a
single process, so (for example) a multithreaded
setuid/setgid process can have a *very* interesting time.
8) rlimit information isn't common to all threads in a
single process.
9) A multithreaded session leader process cannot do
things like disconnecting from a controlling tty
in any thread other than its first.
10) "times" doesn't account for other than the thread it is
called in.
> The people who are affected by the issue most are developers who
> have fairly recently produced a large, non-trivial application on
> another platform that is to be ported to Linux, and which invokes
> the troublesome parts of the interface.
Those "troublesome parts" would be system calls and signals. ;)
> It doesn't affect people who consider the Linux interface from the start. It
> certainly doesn't affect developers of free software that use Linux as one of
> their development platforms.
No, I agree it doesn't affect people who develop _on_ Linux. It does,
however, effect people who expect pthreads to actually be Posix
threads. For a small example, consider bfbtester, a fuzz-like black
box tester (http://my.ispchannel.com/~mheffner/bfbtester) originally
developed on FreeBSD. It spawns the application being tested via exec
for each case, collecting the exit status via waitpid(). Despite the
trivial port to Solaris, it has to be completely rewritten now for the
Linux port, because of item #5 on the thread problem list above.
As to legacy code, it's perfectly reasonable to expect at least some
of these features to work now, especially shared pids. The entire
point of threads is to allow most of those, and not to provide what
basically amounts to a wrapper around fork().
> It sounds risky; it's entirely understandable why the kernel developers would
> not want to risk destabilizing the kernel for the sake of issues that can be
> solved in user space.
The two problems here are that:
1. It could easily be done in a development branch. It's also not
clear exactly how many things would break if we changed the value used
for pid now to a thread idea, and allowed pids to be non-unique.
2. Nobody to date has suggested a feasible way to solve any of the non
conformant problems in user space.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Jonathan Kamens)
Crossposted-To: alt.comp.periphs.mainboard.supermicro
Subject: Re: Can't use both USB printer and Promise Ultra66 at the same time
Date: 20 Aug 2000 01:19:27 GMT
In article <8nlhe1$j7c$[EMAIL PROTECTED]>,
"Jan Welti" <[EMAIL PROTECTED]> writes:
>Why don't you use your printer in the parallel port? Using USB won't have
>any major speed advantage.
Because I've already got another printer plugged into the parallel
port.
>"Tim Moore" <[EMAIL PROTECTED]> wrote in message
>> Turn of PnP in BIOS, then specifically assign IRQ's in BIOS.
I already tried explicitly assigning IRQs. My BIOS lets me do that
even when PnP isn't enabled. It didn't help (in fact, the Promise
card seems to ignore the PnP assignment I give it). I know that the
IRQ assignments in the BIOS are supposed to work even when PnP isn't
enabled because some of my other cards do in fact pay attention to the
assignments.
Are you sure that the PnP setting will make a difference?
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: all threads in a process share the same pid?
From: [EMAIL PROTECTED]
Date: Sun, 20 Aug 2000 02:04:29 GMT
[EMAIL PROTECTED] writes:
> That may be, but you didn't ask for pthreads. What you want is a
> non-standard threading system that maintains a different working
> directory for every thread. On top of that, you said you were willing
> to sacrifice portability in order to have it. That can be fulfilled
> either with:
> 1. A new api, which gives you the current, mangled threads.
Or, perhaps, a new API which does the threading the way it should be
done. The fact that you suggest a "new" API for the "current" system
suggests you're deliberately trying to cast Kaz's suggestion in the
worst possible light.
--
Eric McCoy ([EMAIL PROTECTED])
"rash, n. Insensible to the value of our advice."
- Ambrose Bierce, The Devil's Dictionary
------------------------------
** 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
******************************
