Charl P. Botha wrote:
If by server-recycle you mean stopping and starting X, I haven't seen any
lockups with that.
An X Server recycle is something the X Server does automatically when
the last client disconnects. It basically goes thrue shutdown and
cleanup of everything, then reinitializes
Am Sonntag, 23. Februar 2003 20:59 schrieb Keith Whitwell:
Linus Torvalds wrote:
On Sat, 22 Feb 2003, Keith Whitwell wrote:
What about processes that *don't* do a close - that just use an fd and
exit.
[-]
The answer really is that you shouldn't care about the pid at all.
OK, here's a
Am Donnerstag, 27. Februar 2003 16:06 schrieb Dieter Nützel:
Am Sonntag, 23. Februar 2003 20:59 schrieb Keith Whitwell:
Linus Torvalds wrote:
On Sat, 22 Feb 2003, Keith Whitwell wrote:
What about processes that *don't* do a close - that just use an fd and
exit.
[-]
The answer
Am Donnerstag, 27. Februar 2003 16:09 schrieb Dieter Nützel:
Am Donnerstag, 27. Februar 2003 16:06 schrieb Dieter Nützel:
Am Sonntag, 23. Februar 2003 20:59 schrieb Keith Whitwell:
Linus Torvalds wrote:
On Sat, 22 Feb 2003, Keith Whitwell wrote:
What about processes that *don't* do a
On Thu, 2003-02-27 at 16:09, Dieter Nützel wrote:
Am Donnerstag, 27. Februar 2003 16:06 schrieb Dieter Nützel:
Am Sonntag, 23. Februar 2003 20:59 schrieb Keith Whitwell:
OK, here's a patch, first attempt at doing this. It's not ready to
commit yet, unless we start a branch for this...
Am Donnerstag, 27. Februar 2003 16:21 schrieb Charl P. Botha:
On Thu, 2003-02-27 at 16:09, Dieter Nützel wrote:
Am Donnerstag, 27. Februar 2003 16:06 schrieb Dieter Nützel:
Am Sonntag, 23. Februar 2003 20:59 schrieb Keith Whitwell:
OK, here's a patch, first attempt at doing this. It's
Charl P. Botha wrote:
On Mon, Feb 24, 2003 at 11:41:01AM -0700, Keith Whitwell wrote:
Charl P. Botha wrote:
Keith, is this related to the problems I reported a day or two back with
my/your modified glthreads.c example? I.e., will it also fix the crashes
when deleting a single glxcontext in a
On Wed, Feb 26, 2003 at 09:49:46AM -0700, Keith Whitwell wrote:
Charl P. Botha wrote:
The drmCmdBuffer: -22 is indeed gone. Do you still see the glthreads:
radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext: Assertion vb.context ==
ctx' failed. at startup however?
I haven't reproduced this.
On Wed, Feb 26, 2003 at 09:49:46AM -0700, Keith Whitwell wrote:
Charl P. Botha wrote:
The drmCmdBuffer: -22 is indeed gone. Do you still see the glthreads:
radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext: Assertion vb.context ==
ctx' failed. at startup however?
I haven't reproduced this.
On Mit, 2003-02-26 at 17:49, Keith Whitwell wrote:
Has anyone reproduced the server-recycle hang I reported earlier? I've
changed test machines don't see it any more...
Could be the problem people are complaining about on XFree86 lists and
unrelated to your changes.
--
Earthling Michel
Keith Whitwell wrote:
Linus Torvalds wrote:
On Sat, 22 Feb 2003, Keith Whitwell wrote:
What about processes that *don't* do a close - that just use an fd
and exit.
The exit does a close, and you'll see a flush() from the dying process
(and a release() if that was the last user).
In the
On Sun, Feb 23, 2003 at 12:59:20PM -0700, Keith Whitwell wrote:
Linus Torvalds wrote:
On Sat, 22 Feb 2003, Keith Whitwell wrote:
What about processes that *don't* do a close - that just use an fd and
exit.
The exit does a close, and you'll see a flush() from the dying process
(and a
Felix K?hling [EMAIL PROTECTED] wrote:
No idea, just a comment. This reminded me of the famous X hangs when
flightgear exits. Recently I read in some posts on the plib-users
mailing list that flightgear is multi-threaded, too. The situation is
somewhat different, though. There is only one
On Mon, Feb 24, 2003 at 03:06:24PM +, Alan Hourihane wrote:
On Sun, Feb 23, 2003 at 12:59:20PM -0700, Keith Whitwell wrote:
OK, here's a patch, first attempt at doing this. It's not ready to commit
yet, unless we start a branch for this...
Things actually work pretty well, and a
Charl P. Botha wrote:
On Mon, Feb 24, 2003 at 03:06:24PM +, Alan Hourihane wrote:
On Sun, Feb 23, 2003 at 12:59:20PM -0700, Keith Whitwell wrote:
OK, here's a patch, first attempt at doing this. It's not ready to commit
yet, unless we start a branch for this...
Things actually work pretty
On Mon, Feb 24, 2003 at 11:41:01AM -0700, Keith Whitwell wrote:
Charl P. Botha wrote:
Keith, is this related to the problems I reported a day or two back with
my/your modified glthreads.c example? I.e., will it also fix the crashes
when deleting a single glxcontext in a multi-threaded
Linus Torvalds wrote:
On Sat, 22 Feb 2003, Keith Whitwell wrote:
What about processes that *don't* do a close - that just use an fd and exit.
The exit does a close, and you'll see a flush() from the dying process
(and a release() if that was the last user).
In the threaded demo I'm looking
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
being called only once despite the 3 processes (threads) that are being
On Sat, 2003-02-22 at 22:38, Keith Whitwell wrote:
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
being called only once
On Sat, 22 Feb 2003 15:38:40 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
Alan Cox wrote:
On Sat, 2003-02-22 at 22:38, Keith Whitwell wrote:
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
being
Alan Cox wrote:
On Sat, 2003-02-22 at 22:38, Keith Whitwell wrote:
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
being
On Sat, 22 Feb 2003, Keith Whitwell wrote:
So, was the gist of the fix to simply relocate the current release() stuff to
flush()? I'm going to go read the code now.
Yes, either that, or you need to not care about pid's.
release() is not necessarily called _at_all_ within the context of
Linus Torvalds wrote:
On Sat, 22 Feb 2003, Keith Whitwell wrote:
So, was the gist of the fix to simply relocate the current release() stuff to
flush()? I'm going to go read the code now.
Yes, either that, or you need to not care about pid's.
release() is not necessarily called _at_all_
On Sat, 22 Feb 2003, Keith Whitwell wrote:
Does flush get called when the process (thread) dies as well? I'm seeing
identical behaviour for flush() as release() -- both are being called once
despite multiple threads holding copies of the fd.
Threads share the file descriptors, so in a
On Sat, 22 Feb 2003, Keith Whitwell wrote:
What about processes that *don't* do a close - that just use an fd and exit.
The exit does a close, and you'll see a flush() from the dying process
(and a release() if that was the last user).
In the threaded demo I'm looking at, there is only one
I'd suggest associating the struct file_struct * with the GL context,
and nothing else.
At that point you would always get the right answer by just knowing that
when the release() happens, the GL context is gone.
This is probably the only sensible solution, I think.
Keith
27 matches
Mail list logo
