Re: [Freedce-devel] pthread_clear_exit_np()

[Luke Kenneth Casson Leighton]

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(a)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
>   
-- 
--
lkcl.net - mad free software computer person, visionary and poet.
--

[KJKHyperion]

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)

[Steven Edwards]

On 4/28/06, KJKHyperion <hackbunny(a)reactos.com> wrote:
>   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) 
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

[Alex Ionescu]

Steven Edwards wrote:

On 4/28/06, KJKHyperion <hackbunny(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[KJKHyperion]

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

[Steven Edwards]

On 4/28/06, KJKHyperion <hackbunny(a)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

[James Tabor]

HI!
Steven Edwards wrote:
>   On 4/28/06, KJKHyperion <hackbunny(a)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

[Magnus Olsen]

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

[Peter Dolding]

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(a)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.

[KJKHyperion]

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

[Jonathan Wilson]

>   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)

[Steven Edwards]

On 5/3/06, Jonathan Wilson <jonwil(a)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

[Peter Dolding]

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