On Tue, 26 Sep 2000, Thomas Zehetbauer wrote:
> > But if you can get rid of the stacks, and you _can_ get rid of the
> > stacks sometimes, then why not have one thread per widget in a GUI? Or
> > one thread per animated objected on a web page? Some notions of
> For this to work without opening
> But if you can get rid of the stacks, and you _can_ get rid of the
> stacks sometimes, then why not have one thread per widget in a GUI? Or
> one thread per animated objected on a web page? Some notions of
For this to work without opening up a security hole we must be able to
distribute the pr
> quote> SCO's Juergen Kienhoefer tells us that by mapping clone processes
> quote> directly onto UnixWare's native threads, huge performance gains
> quote> can be realised. "Basically thread creation is about a thousand
> quote> times faster than on native Linux," he said. The performance boost
>
Hi!
> > CODA's local caching is pretty much neccessity: you can't have
> > read/write server in userland on localhost at smaller granularity due
> > to deadlock issues.
>
> For distributed filesystem - yes (but not necessary). For other kinds of
> stuff - provably not true.
Okay, how do you imp
On Fri, 1 Sep 2000, Pavel Machek wrote:
> CODA's local caching is pretty much neccessity: you can't have
> read/write server in userland on localhost at smaller granularity due
> to deadlock issues.
For distributed filesystem - yes (but not necessary). For other kinds of
stuff - provably not t
Hi!
> > * podfuk is has file granularity
> >
> > I could see it working with some kind of directory format, however.]
>
> Yep. And quite a few mailreaders can work with that. I'm less than sure
> that CODA's local caching is appropriate, though. More RPC-oriented
> stub
CODA's local caching is
On Thu, 31 Aug 2000, Erik McKee wrote:
> Hello!
>
> This is one of my first posts here, so try to be gentle, please ;)
>
> Seems like if a thread which shares a VM with all the other threads of the
> same family does an execve, the following would be likely to occurr, using
> the standard defin
Hello!
This is one of my first posts here, so try to be gentle, please ;)
Seems like if a thread which shares a VM with all the other threads of the
same family does an execve, the following would be likely to occurr, using
the standard definition of execve. The vm would be overwriteen with the
[EMAIL PROTECTED] (Linus Torvalds) wrote on 27.08.00 in
<[EMAIL PROTECTED]>:
> On Sun, 27 Aug 2000, Alexander Viro wrote:
> >
> > Linus, there is no need in new mask for execve().
>
> What you're saying is "there are other ways to accomplish this". And I
> kind of agree. I still think the dynam
On Tue, 29 Aug 2000, Pavel Machek wrote:
> What does this have to do with private namespaces?
Albert asked what to do if /var/spool/mail dies and every user
has his own namespace. Well, don't let him play with /var/spool/mail
directly...
> mailfsd /dev/coda0 --enable-imap &
> mount /d
On Tue, 29 Aug 2000, Pavel Machek wrote:
> Hi!
>
[...]
> > > So you need some hackery to make mount(8) cause change in all
> > > namespaces at once. Whatever is done, this will be gross.
> > > I suppose you'd require a loopback of some sort, so that one
> > > might rip the real filesystem out fr
Hi!
> > > Erm?
> > > * setuid is a fscking wart - THE mistake of dmr and/or ken.
> >
> > If not urban legend, dmr was the patent owner.
>
> Erm... That would be a nice way to bury one's mistake - patent it and
> refuse to license ;-) Unfortunately, didn't happen...
(-:
> > So you need some
On Tue, 29 Aug 2000, Albert D. Cahalan wrote:
> Proposal 'c' is that way. If you agree that "VM is just one of
> the resources" but think that there are "uses for sharing between
> different programs", proposal 'a' is for you.
Sorry, no. VM is the resource that execve() replaces. That is what
Alan Cox wrote:
> It isnt a sensible answer. Think about a threaded web server firing off
> cgi scripts. You should probably kill those with the same mm. Especially if
> you have an unclone(CLONE_MM) since you can then unshare the VM for a thread
> and exec stuff off it
Think about a single thre
Alexander Viro writes:
> On Tue, 29 Aug 2000, Albert D. Cahalan wrote:
[interaction w/ setuid, close-on-exec, and personality pseudo-roots]
> We _have_ this interaction. In case you've missed it, sys_personality()
> that really happens to change personality unshares fs_struct. Has to.
> Rule: yo
From: "David Howells" <[EMAIL PROTECTED]>
>
> Would it be possible to make fork() or clone() from a process whose
tgid!=pid
> reparent the child to the thread group leader automatically? Thus, when
the
> creating thread goes away, the child is still a child of the "process",
and
> SIGCHLD is still
Would it be possible to make fork() or clone() from a process whose tgid!=pid
reparent the child to the thread group leader automatically? Thus, when the
creating thread goes away, the child is still a child of the "process", and
SIGCHLD is still going to go to the process (leader thread).
Also
On Tue, Aug 29, 2000 at 02:12:17PM +0200, Marc Lehmann wrote:
> On Mon, Aug 28, 2000 at 09:20:49AM -0600, [EMAIL PROTECTED] wrote:
> > You can't rely on signals timing anyway -- that is quite clear in the
> > spec and in the implementation.
>
> there is no "spec" on how it should be done. Again,
18 matches
Mail list logo
