This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Cygwin.dll crash, alloca and custom stack


> From: "Gary R. Van Sickle  wrote:
> >In the post you're replying to, I listed the legitimate reasons for 
> >wanting to do it.  Here they are again:
> >
> >- If you're writing a task switcher.
> 
> And what's the difference between a task switcher and 
> switching between co-routines?

You seem to already have all the answers you ostensibly came here to seek,
so I expect you'll be answering that question for me.

> Basically nothing at all 

My expectation has been fulfilled.

> except that a task gets switched whenever the OS wants to, 
> whereas a co-routine gets switched under program control.

Really?  So these "coroutines" are totally under the Scheme programmer's
control, the OS has nothing to do with them, but if I, say, spawn a thread,
it's off to never-never land and I have no control over it?

> So 
> why must they be implemented differently?

I guess they musn't.  As you've already figured out, you should use the
platform's existing task switching facilities to implement these coroutines,
and drop this silly notion of manhandling esp.

> It's nothing new to 
> be writing user space task switchers that switch stacks,

When was the last time you did it on either Windows or Linux with gcc?

> I 
> see no reason why a user space co-routine switcher should not 
> do the same.
> 

That's because you're looking the other way.

> >Do you actually realize that there are far better ways to implement 
> >stacks for interpreters than dinking with esp?
> 
> I realise there are a dozen ways to suck eggs.

I thought your goal was to write a Scheme interpreter with as little pain as
possible.

> But do YOU 
> realise

If I do, I don't care.  I'm not the one who came here for help and then
became belligerent when it was offered.

> that there
> 
> are two ways to implement a language with co-routines, 
> whether it be interpreted or compiled, and that is to either 
> have a vm with a fake stack, or to use the machine's real 
> stack.

Or to spawn the coroutine as a thread (or fiber) as Chris Faylor pointed
out, and let the OS and CRT operate as they were designed to operate.

> And if you use the machine's real stack you MUST 
> "dink" with esp. You MUST.

Then you'd better not use the machine's real stack.

> I don't happen to be writing a VM 
> based interpreter with a fake stack.
> 

Chris, you're so wildly out in left field on this no-brainer issue that
there's no way you'll be writing any sort of interpreter.

> >I suggest you investigate those alternatives instead of trying to do 
> >something that cannot work, and then getting all pissy when 
> people try
> to
> >dissuade you from wasting your time. 
> 
> That's strange. Now that I know that on Windows it likes to 
> use its own stack for system calls, its working fine by just 
> restoring the system stack temporarily. I can switch stacks 
> and co-routines with no problems at all. So much for your 
> bogus "cannot work". I guess you don't know everything after 
> all huh?

I guess it is in fact you who knows all.  I stand humbled, and hope that
your esp-mangling-via-gcc-asm()-statements Scheme interpreter works as well
tomorrow as it did today.

> I do remain curious why Windows actually cares 
> whereas Linux acts sensibly and doesn't carebut it matters 
> little for my purposes. 
> 

...until something goes wrong, which it will, and you can't figure out why.
But I guess you can be assured that it has nothing whatsoever to do with
manhandling esp, so you have that going for you, which is nice.

> >No, but there is a law that you have to learn to walk before 
> you can run.
> >You are trying to sprint a marathon before you're even able 
> to stand erect.
> 
> 
> Meaningless ad-hominem.

You refuse to acknowledge that C has a runtime.  There was nothing
meaningless about that ad-hominem, Mr. Sees-An-Insult-Under-Every-Metaphor.

> I guess now that I've got it working, 
> if I can't stand erect, you must not even be crawling. 
> 

"SNAP!", as the kids say these days.

> >Christopher Faylor <cgf-no-personal-reply-please at cygwin 
> dot com> wrote:
> >What you are trying to do is a bad idea.  
> 
> Bad huh? I'm fuzzy on the whole good/bad thing. Care to elaborate? 
> 

Dinking with esp via asm() statements: bad.
Combining replies to two different posts into one: bad.
Learning how to write code that at least has a fighting chance of not being
a disaster: good.

> >Btw, have you thought about how to handle stack overflow?  
> What happens 
> >when the program pushes its way to the top of your malloced region?
> 
> Each Scheme function call has its own environment that is 
> chained to previous environments. Each environment has its 
> own stack. The C code that executes a scheme function uses a 
> small and well-defined amount of stack.
> Restoring the system stack for external library calls is 
> going to be a good idea anyway, because they can use 
> arbitrary amounts of stack.

Wow.  Yeah, well, I guess that is technically on the list of reasons not to
be screwing around with your stack pointer in C code, somewhere down around
#431.

> But for the interpreter itself 
> the exact amount of stack required for one lambda can be 
> calculated by trial and error. The other way to implement it 
> is to copy the entire stack when switching co-routines, but 
> I'm trying to avoid that.

Hear me now and believe me later: this project is way beyond your abilities
and experience, and your "Only help me if you're going to tell me I'm doing
things the right way" attitude puts the final nail in this project's coffin.
If you wish to succeed in writing a C program, don't even think about
"asm()" for several more years.  And don't worry: there's plenty of problems
to be had without having to invoke "asm()".

-- 
Gary R. Van Sickle
 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]