Re^16: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?

Because all that should be needed (on windows) is
#define PERL_GET_CONTEXT TlsGetValue(PL_thr_key)
#define PERL_SET_CONTEXT(t) TlsSetValue(PL_thr_key, (t))
download
Quite why those calls are bracketed to preserve information from a previous error is strange.
What previous error have we ignored -- by continuing to this piece of code -- that we want to retain the extended error information for?
And what are we going to do with that retained information? And when?

You do realize your idea will break $^E?

Remember there is this questionable file that can steal your C lib away from you, win32/win32iop.h in perl.git.

errno is nearly useless on Windows since its so vague and rarely set compared to LastError/$^E. Side note, on a nytprof profiler in my experience, Win32::GetLastError() is 10 times faster than $^E. Perl does its best to always keep Win32's last error accurate to the last Win32 call you consciously made (CRT things, like malloc or free, or Kernel32 HeapAlloc (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366597%28v=vs.85%29.aspx), should not and do not change LastError), otherwise a mortal sweeping at scope boundaries would make LastError absolutely useless in perl as it frees SVPVs and make it impossible to do many Win32-ish things. Sometimes I've had GetLastError be screwed up in Perl because a

$obj = Win32::Foo->new("create me");
#new returned a blessed object
$obj = Win32::Foo->new("dont create me");
#new returned undef and LastError has failure code, DESTROY of "create
+ me" fires, changes LastError
if(! defined  $obj){
     #$^E happens to be ERROR_SUCCESS (it is actually undefined/random
+), programmer pounds head on keyboard screaming WHY ME!!!!
     die "creating obj failed ".($^E+0);
}
[download]

IMHO, LastError is a terrible design. Native API's NTSTATUS error code system is much better thought out (http://msdn.microsoft.com/en-us/library/cc231200%28v=prot.10%29) with positive signed numbers being informational non-errors, 0 being success with no information, and negative being errors.

Comment on Re^16: Perl 5 Optimizing Compiler, Part 4: LLVM Backend? Download Code

Replies are listed 'Best First'.
Re^17: Perl 5 Optimizing Compiler, Part 4: LLVM Backend? by BrowserUk (Patriarch) on Aug 30, 2012 at 08:14 UTC
You do realize your idea will break $^E? It not "my idea".... Please think about the following sequence of events: User program calls some built-in or XS function. Program enters C ... ... does some stuff ... Still in C An system API is called, that fails and causes GetLastError() to be set. Still in C Oh. Let's fiddle with the context at this point But we must preserve that extended error information So that when we get around to telling the user that the other API we called, failed, he can query for some extra information ... do some more stuff ... return (failure) to user. Think. What API might we be calling at 3, that fails, but not so badly that we can't fiddle with the context, before we report that failure back to user, who might want to get the extended error information? And, if SetContext should fail, is the extended error information from that mysterious API still important? Will we ever get back to the user for him to be able to query that extended error information? Details. Details... Off topic. Let's stop. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP Neil Armstrong	[reply]
Re^18: Perl 5 Optimizing Compiler, Part 4: LLVM Backend? by bulk88 (Priest) on Aug 30, 2012 at 17:09 UTC
The LastError does not survive, on failure OR success, through anything that sets LastError on failure. So even if TlsGetValue was successful, it presumably changed LastError, therefore masking the original error.	[reply]
Re^19: Perl 5 Optimizing Compiler, Part 4: LLVM Backend? by BrowserUk (Patriarch) on Aug 30, 2012 at 17:22 UTC
therefore masking the original error. Yes. But you're still missing the point. Who is ever going to want to see the original error, if between it occurring and them being able to get their hands on it, the internals have gone on to mess with the context? Under what circumstances, is that information going to be useful to anyone, if the context has changed in the interim? I say: no one. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP Neil Armstrong	[reply]