okay, so these are the options:
1) forget redhat and forget them ever being helpful and supporting strategically important free software projects, and go back to using dcethreads posix draft 4 "emulation".
2) forget redhat and forget them ever being helpful and supporting strategically important free software projects, and put the cancellation "wrapper" side back into the dcethreads library - just keep the same posix "final draft" API.
lord only knows what would happen on pthreads-win32 when compiling freedce with mingw32, with the "wrapper" stuff back in, but i'd be fascinated to find out.
3) think of ways to persuade the developers of glibc to enter into reasonable conversations and dialog to help support a strategically important free software project. how does any other project manage this (and what in hell's name prompted ulrich to be so dismissive?)
On Fri, Apr 21, 2006 at 05:26:44PM +0200, thomas.schuetzkowski@web.de wrote:
Hi Luke,
To make this work with libc we need to "un-cancel" a thread. ... Of course, using this in a third-party application is problematic as it depends on internal glibc structures.
I know the chances of such an API being added to glibc are about nil, but I thought I'd mention this anyway! :-)
We thought about adding a detection of the glibc version to autoconf stuff and choose the right version of the function. (see Loic's patch) Then of course someone has to maintain this for every new version of glibc. :-(
This idea was skipped, because no one had the time to do this.
regards, Thomas _______________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
Luke Kenneth Casson Leighton wrote:
"uncancel" a thread? really sounds like exception filtering. You know, like in SEH. As I see it, there's another option:
4) get these freaking bigots to learn how SEH works. SEH can implement everything you need and so much more. The DCE exception handling API? a portable subset of SEH. C++ exception handling? a type-safe wrapper on SEH, with less features. Just give up and adopt SEH, spare yourself a lot of pain reinventing it. It won't change how you do things now, and it will make everything easier. Concerns about portability? SEH worked unchanged on five completely unrelated operating systems (Windows, Windows NT, OS/2, VMS, Tru64) and countless hardware architectures (x86, Alpha, PowerPC, MIPS, ARM, Sh, IA64, x86-64, really anything that's ever been thrown at it)
On 4/28/06, KJKHyperion hackbunny@reactos.com wrote:
- get these freaking bigots to learn how SEH works. SEH can implement
everything you need and so much more. The DCE exception handling API? a portable subset of SEH. C++ exception handling? a type-safe wrapper on SEH, with less features. Just give up and adopt SEH, spare yourself a lot of pain reinventing it. It won't change how you do things now, and it will make everything easier. Concerns about portability? SEH worked unchanged on five completely unrelated operating systems (Windows, Windows NT, OS/2, VMS, Tru64) and countless hardware architectures (x86, Alpha, PowerPC, MIPS, ARM, Sh, IA64, x86-64, really anything that's ever been thrown at it)
SEH is also patented which means its dead in the water for most free software projects.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Steven Edwards wrote:
On 4/28/06, KJKHyperion hackbunny@reactos.com wrote:
PS: all cries of "but it's UNDOCUMENTED! PATENTED! mommy sais it will make HAIR grow from my PALMS!" will be appropriately derided
SEH is also patented which means its dead in the water for most free software projects.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Steven Edwards wrote:
SEH is also patented which means its dead in the water for most free software projects.
oh dear. First: HAHAHAHAHA LOOK AT THE MAMA'S BOY, CRY BOY CRY. Then: it's not "patented" per se. Only the stack-based implementation on x86 (NO WE CANNOT USE ANOTHER IMPLEMENTATION. Really beary totally absolutely positively sure), and even then only if compiler-integrated. Since GCC doesn't use stack-based exception handling *anywhere*, not even on x86, that'd be a total non-issue. On operating systems as yet unblessed by SEH it'd be even better as a starting point: a single implementation shared by all architectures upfront. And lack of compiler support is only really a problem on non-x86, because on x86 you can use PSEH, which isn't covered by the patent
On 4/28/06, KJKHyperion hackbunny@reactos.com wrote:
oh dear. First: HAHAHAHAHA LOOK AT THE MAMA'S BOY, CRY BOY CRY. Then: it's not "patented" per se. Only the stack-based implementation on x86 (NO WE CANNOT USE ANOTHER IMPLEMENTATION. Really beary totally absolutely positively sure), and even then only if compiler-integrated. Since GCC doesn't use stack-based exception handling *anywhere*, not even on x86, that'd be a total non-issue. On operating systems as yet unblessed by SEH it'd be even better as a starting point: a single implementation shared by all architectures upfront. And lack of compiler support is only really a problem on non-x86, because on x86 you can use PSEH, which isn't covered by the patent
I would say I agree that PSEH was a option even if the syntax is not 100% compatible and it could be a good case for someone like Luke working on pretty pseh seeing as it was rotting the last time I checked but rather than have a productive discussion about the issues I'll switch to further ad-hominem,
Piss off, get a life, do something productive or just shut the fuck up.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
HI! Steven Edwards wrote:
On 4/28/06, KJKHyperion hackbunny@reactos.com wrote:
oh dear. First: HAHAHAHAHA LOOK AT THE MAMA'S BOY, CRY BOY CRY. Then: it's not "patented" per se. Only the stack-based implementation on x86 (NO WE CANNOT USE ANOTHER IMPLEMENTATION. Really beary totally absolutely positively sure), and even then only if compiler-integrated. Since GCC doesn't use stack-based exception handling *anywhere*, not even on x86, that'd be a total non-issue. On operating systems as yet unblessed by SEH it'd be even better as a starting point: a single implementation shared by all architectures upfront. And lack of compiler support is only really a problem on non-x86, because on x86 you can use PSEH, which isn't covered by the patent
I would say I agree that PSEH was a option even if the syntax is not 100% compatible and it could be a good case for someone like Luke working on pretty pseh seeing as it was rotting the last time I checked but rather than have a productive discussion about the issues I'll switch to further ad-hominem,
Piss off, get a life, do something productive or just shut the fuck up.
LOL! YEAH! We are getting back to normal!
-- Steven Edwards
Thanks, James
Hi SVN is tempary down. I do not know which time it will be up again. I hope it will solv soon, I have mail fireball to infrom him about it
Bestreagds Magnus Olsen ReactOS Devloper
KJKHyperion wrote:
Steven Edwards wrote:
SEH is also patented which means its dead in the water for most free software projects.
oh dear. First: HAHAHAHAHA LOOK AT THE MAMA'S BOY, CRY BOY CRY. Then: it's not "patented" per se. Only the stack-based implementation on x86 (NO WE CANNOT USE ANOTHER IMPLEMENTATION. Really beary totally absolutely positively sure), and even then only if compiler-integrated. Since GCC doesn't use stack-based exception handling *anywhere*, not even on x86, that'd be a total non-issue. On operating systems as yet unblessed by SEH it'd be even better as a starting point: a single implementation shared by all architectures upfront. And lack of compiler support is only really a problem on non-x86, because on x86 you can use PSEH, which isn't covered by the patent _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Dwarf2 is stack-based and integrated into gcc on a lot of platforms. It uses a slightly different wording frame based. Basic operation is the same. Note if stack-based processor operations were patented Intel would hold the patent not Borland since they developed the processor features that let it happen. Its the system of Microsoft/Borland SEH that is patented. Dwarf2 is a completely independently developed using a different system. Same interfaces to processor. Dwarf2 is not locked to x86 processors. Dwarf2 has now been extended to Dwarf3 to do support of pure 64 bit systems.
Non issue. KJKHyperion not true. A system exists in gcc for frame based exception handling. Its used. Only recently did mingw catch up. Even djgpp for dos has had it for years. Mingw is the last gcc to get it.
PSEH with double mode would solve all the problems. Dwarf2/3 could be used to cover platforms not covered by x86 and even x86 where Dwarf2/3 is supported by the complier.
Even Dwarf system has other advantages. Remote debuging is supported on lot more different processors. Every wonder how Linux is debuged on some of its strange processors. The trick is dwarf. A OS cannot develop without some form of exception handling. Example GNU Hurd. Complete stuffed for a long time because of the lack of tools to debug it.
Peter Dolding wrote:
Dwarf2 is stack-based and integrated into gcc on a lot of platforms. It uses a slightly different wording frame based. Basic operation is the same. Note if stack-based processor operations were patented Intel would hold the patent not Borland since they developed the processor features that let it happen.
nopes, Borland were the first to do stack-based exception handling. Everyone else used sensible architectures with native unwinding and exception handling based on function tables (yes, checked. SEH was developed in parallel on Alpha, VAX and x86 - the aforementioned Tru64, VMS and OS/2 implementations. And the tradition started back then). And besides, wonderful. Microsoft moves away from stack-based and GCC adopts it? we're screwed. Also: does it support exception handling in C too, now? or only C++? Because we need it in C. GCC's C++ compiler is too slow to turn e.g. our whole kernel into C++, and we have the impression that it generates gigantic executables. Finally: I see no mention in the DWARF specifications of exception handling standards, is this an abusive appropriation of the name as an obscure reference to some GCC internals?
Its the system of Microsoft/Borland SEH that is patented. Dwarf2 is a completely independently developed using a different system. Same interfaces to processor. Dwarf2 is not locked to x86 processors. Dwarf2 has now been extended to Dwarf3 to do support of pure 64 bit systems.
stack-based SEH doesn't depend on x86, either, and I find it much better on the whole. In fact, if we can piss on non-x86 compatibility (at least temporarily), I'd be very happy to port PSEH (it needs only minimal platform-specific code) - I think our system support for exception handling could easily support both, even. It's just the way it is in the real world
Non issue. KJKHyperion not true. A system exists in gcc for frame based exception handling. Its used. Only recently did mingw catch up. Even djgpp for dos has had it for years. Mingw is the last gcc to get it.
hey, it's not like we didn't pressure them all the time. And to repeat myself, we need this in C. Not C++. Absolutely sure of it. And we'll need it to catch faults, such as memory access violations, not just program exceptions - in fact, that's what using SEH in the kernel is all about
hey, it's not like we didn't pressure them all the time. And to repeat myself, we need this in C. Not C++. Absolutely sure of it. And we'll need it to catch faults, such as memory access violations, not just program exceptions - in fact, that's what using SEH in the kernel is all about
Can someone explain to me why someone doesnt just go and bgab the MingW/GCC source code and write a proper SEH implementation that is source-level and binary-level compatible with the MS implementation (i.e. it uses the same source syntax as the MS implementation and the same OS functionality and mechanisim as the MS implementation)
I have seen several "under the hood" documents explaining exactly how SEH works at the OS level (I even have code that for various reasons I wont go into needs to walk the exception handler list and remove a particular handler from the list in order to make something work right) so its not like its undocumented or a black art (unlike many of the pieces of windows ReactOS needs to implement and be compatible with)
On 5/3/06, Jonathan Wilson jonwil@tpgi.com.au wrote:
Can someone explain to me why someone doesnt just go and bgab the MingW/GCC source code and write a proper SEH implementation that is source-level and binary-level compatible with the MS implementation (i.e. it uses the same source syntax as the MS implementation and the same OS functionality and mechanisim as the MS implementation)
Casper started doing this, in fact the gcc google summer of code page suggests adding SEH support so it might be possible to get them to merge it up stream now. Its possible the view on the patent has changed after Borlands statement regarding SEH and Winelib.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
KJKHyperion wrote:
Peter Dolding wrote:
Dwarf2 is stack-based and integrated into gcc on a lot of platforms. It uses a slightly different wording frame based. Basic operation is the same. Note if stack-based processor operations were patented Intel would hold the patent not Borland since they developed the processor features that let it happen.
nopes, Borland were the first to do stack-based exception handling. Everyone else used sensible architectures with native unwinding and exception handling based on function tables (yes, checked. SEH was developed in parallel on Alpha, VAX and x86 - the aforementioned Tru64, VMS and OS/2 implementations.
And the tradition started back then). And besides, wonderful. Microsoft moves away from stack-based and GCC adopts it? we're screwed. Also: does it support exception handling in C too, now? or only C++? Because we need it in C. GCC's C++ compiler is too slow to turn e.g. our whole kernel into C++, and we have the impression that it generates gigantic executables. Finally: I see no mention in the DWARF specifications of exception handling standards, is this an abusive appropriation of the name as an obscure reference to some GCC internals?
Nop You will find the worlds worse manual here. http://dwarf.freestandards.org/Home.php. Understanding the standard spec almost takes a PHD. This person tried to make it common sense. http://gcc.gnu.org/ml/gcc/2002-07/msg00391.html. Dwarf 2/3 is not locked to C++. I would not have mentioned it if it was locked to C++. I like that you mention unwinding. Guess what dwarf forces sensible unwinding. Unwinding of errors frame handling of errors comes under debuging.
stack-based SEH doesn't depend on x86, either, and I find it much better on the whole. In fact, if we can piss on non-x86 compatibility (at least temporarily), I'd be very happy to port PSEH (it needs only minimal platform-specific code) - I think our system support for exception handling could easily support both, even. It's just the way it is in the real world
Where are do you need porting to?? I really mean where. Find somewhere that Dwarf 2/3 is not there already Win32/64 is about last place for dwarf to appear. The argument over if Gcc should support SEH or Dwarf on windows platforms delayed Dwarf on Mingw. Port PSEH to support Dwarf and that is that. Note if all it needs to operate is Dwarf then OS/X, Linux, FreeBSD and even DJGPP on DOS will all support it overnight. Also gain PSEH optimization like the C++ is gaining without using C++.
Non issue. KJKHyperion not true. A system exists in gcc for frame based exception handling. Its used. Only recently did mingw catch up. Even djgpp for dos has had it for years. Mingw is the last gcc to get it.
hey, it's not like we didn't pressure them all the time. And to repeat myself, we need this in C. Not C++. Absolutely sure of it. And we'll need it to catch faults, such as memory access violations, not just program exceptions - in fact, that's what using SEH in the kernel is all about
Dwarf EH was built for C,C++, fortran. Note I might have missed a few other langs. For correct optimization of the Dwarf EH the complier and linker need to support it. Mingw Gcc until just recently has not supported Dwarf at all. Patched version now has it. You can use Dwarf Exception handling without it in the complier and linker too. Just not as effective.
Reactos is Small fish. I mean Small fish. When OS/X Linux and FreeBSD want exception handling one way and Reactos wants it the other. That is why gcc supports Dwarf. I will say that a PSEH over DWARF would be greatly like by people like me who build stuff on Linux. DWARF EH done in C is not the nicest EH you can find even using nasty C hacks are nicer.
The Dwarf handling code in gcc is in the libgcc.a included with almost all langs built with gcc. Normally it has nothing to do with C++ other than improving C++ exceptions. LD on supported platforms can optimize the Dwarf EH. I really wish Dwarf had not got into the Linux Standard Base and something better had got there. Problem there was nothing else operating cross processor at the time Dwarf won by default.
Peter Dolding
-
Alex Ionescu -
James Tabor -
Jonathan Wilson -
KJKHyperion -
Luke Kenneth Casson Leighton -
Magnus Olsen -
Peter Dolding -
Steven Edwards