At 4:15 PM -0400 5/29/02, Josh Wilmes wrote:
At 15:22 on 05/29/2002 EDT, Dan Sugalski [EMAIL PROTECTED] wrote:
I think we'll be safe using longjmp as a C-level exception handler.
I'm right now trying to figure whether it's a good thing to do or
not. (I'd like to unify C and Parrot level
On Tue, May 28, 2002 at 05:47:56PM -0700, Hong Zhang wrote:
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point, having considered the
alternatives, I wish it were otherwise but it's not. Too bad for us.
I think this statement
On Tue, 28 May 2002, Hong Zhang wrote:
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point, having considered the
alternatives, I wish it were otherwise but it's not. Too bad for us.
I think this statement is not very accurate.
On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
Dan may have been referring to the fact that on some key platforms
(Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
use inside of threads.
Is it really unsafe on these platforms?
- According to the Unix
At 8:24 PM +0200 5/29/02, Jerome Vouillon wrote:
On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
Dan may have been referring to the fact that on some key platforms
(Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
use inside of threads.
Is it really
On Wed, 29 May 2002, Jerome Vouillon wrote:
On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
Dan may have been referring to the fact that on some key platforms
(Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
use inside of threads.
Is it really
At 10:53 AM +0100 5/29/02, Dave Mitchell wrote:
On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
Parrot has to handle signals, such as SIGSEGV.
That's the one signal I really hope parrot *doesn't* handle.
What, you don't think we should wedge ourselves into the system MMU
At 5:47 PM -0700 5/28/02, Hong Zhang wrote:
Okay, i've thought things over a bit. Here's what we're going to do
to deal with infant mortality, exceptions, and suchlike things.
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point,
On Wed, May 29, 2002 at 03:23:41PM -0400, Dan Sugalski wrote:
At 10:53 AM +0100 5/29/02, Dave Mitchell wrote:
On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
Parrot has to handle signals, such as SIGSEGV.
That's the one signal I really hope parrot *doesn't* handle.
What,
I've checked with some Sun folks. My understanding is that if you
don't do a list of what I'd consider obviously stupid things like:
*) longjmp out of the middle of an interrupt handler
*) longjmp across a system call boundary (user-system-user and the
inner jumps to the outer)
*)
At 2:24 PM -0500 5/29/02, David M. Lloyd wrote:
But in that case I agree with Dan's
analysis that flags should be used for signal handling just because
writing portable signal handling code that does much more (in a
potentially threaded environment) than that is very complicated.
Right, this is
Actually I'd been given dire warnings from some of the Solaris folks.
Don't use setjmp with threads!
I've since gotten details, and it's Don't use setjmp with threads
and do Stupid Things.
I used to be at Sun. I knew those warnings too. If we use longjmp
carefully, we can make it. In the
On Wed, 29 May 2002, Hong Zhang wrote:
Actually I'd been given dire warnings from some of the Solaris folks.
Don't use setjmp with threads!
I've since gotten details, and it's Don't use setjmp with threads
and do Stupid Things.
I used to be at Sun. I knew those warnings too. If we
I used to be at Sun. I knew those warnings too. If we use longjmp
carefully, we can make it. In the worst case, write our own version.
..Or we could use setcontext/getcontext, could we not?
The setcontext/getcontext will be much worse than setjmp/longjmp.
The are more platform specific
On Wed, 29 May 2002, Hong Zhang wrote:
I used to be at Sun. I knew those warnings too. If we use longjmp
carefully, we can make it. In the worst case, write our own version.
..Or we could use setcontext/getcontext, could we not?
The setcontext/getcontext will be much worse than
At 15:22 on 05/29/2002 EDT, Dan Sugalski [EMAIL PROTECTED] wrote:
I think we'll be safe using longjmp as a C-level exception handler.
I'm right now trying to figure whether it's a good thing to do or
not. (I'd like to unify C and Parrot level exceptions if I can)
Just make sure that we
When I was working on HotSpot JVM, we had some problems with getcontext.
They work 99.99% of time. We added many workaround for the .01% cases. I
believe the Solaris guys have been improving the code. I am not sure of
the current status.
Was that inside of a signal handler or just in
Okay, i've thought things over a bit. Here's what we're going to do
to deal with infant mortality, exceptions, and suchlike things.
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point, having considered the
alternatives, I wish
At 5:47 PM -0700 5/28/02, Hong Zhang wrote:
Okay, i've thought things over a bit. Here's what we're going to do
to deal with infant mortality, exceptions, and suchlike things.
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point,
The thread-package-compatible setjmp/longjmp can be easily implemented
using assembly code. It does not require access to any private data
structures. Note that Microsoft Windows Structured Exception Handler
works well under thread and signal. The assembly code of __try will
show you how to
20 matches
Mail list logo
