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
> > 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
> *) Expect POSIX's dead-stupid mutexes to magically unlock
Hmmm, are we confident that we can write exception handling and stack
rollback code that will always clean up mutexes?
--
"There's something wrong with our bloody ships today, Chatfield."
Admiral Beatty at the Battle of Jutland, 31st M
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 w
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
> > 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 specif
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 warning
> 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.
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
> 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)
>
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.
>
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 thi
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
hand
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
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 i
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 Uni
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 accur
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 stat
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.
Dave.
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.
> >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
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 thi
> 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 w
22 matches
Mail list logo
