1. Multitask Feedback
I like the functions and concept of the new multitasking library. However I
would like to see this remain as an optional only. I'm strongly against the
idea of craming the Interpretor with stuff that would not get used on a day
to day basis.
P.S. I like it very much though.
2. Re: Multitask Feedback
Hayden McKay wrote:
>
> I like the functions and concept of the new multitasking library. However I
> would like to see this remain as an optional only. I'm strongly against the
> idea of craming the Interpretor with stuff that would not get used on a day
> to day basis.
>
> P.S. I like it very much though.
>
I agree. I will most likely never use these multitasking routines. However,
there are those who do need them and need them to be fast (ie. inside the
interpreter) and they can be useful in certain circumstances. These will also
help Euphoria be more of a "legitimate" langauge in many circles though.
The Euphoria Standard Library project :
http://esl.sourceforge.net/
The Euphoria Standard Library mailing list :
https://lists.sourceforge.net/lists/listinfo/esl-discussion
3. Re: Multitask Feedback
> I like the functions and concept of the new multitasking library. However=
I
> would like to see this remain as an optional only. I'm strongly against t=
he
> idea of craming the Interpretor with stuff that would not get used on a d=
ay
> to day basis.
I believe multitasking must be built in. Each task gets its on private
stack, as well as better timing, since it is handled internally. I'm
sure fractions of seconds are lost in the interpreted timing process
as opposed to the internal timing process.
What I'd like to see is task crash handling:
Example:
1. A task is created and started.
2. The task crashes due to a runtime error.
3. Your crash routine is called with the task id.
4. Your crash routine notifies the user.
5. Your crash routine returns true/false to fail or continue.
Just a thought!
~Greg
4. Re: Multitask Feedback
Greg Haberek wrote:
<snip>
> What I'd like to see is task crash handling:
>
> Example:
>
> 1. A task is created and started.
> 2. The task crashes due to a runtime error.
> 3. Your crash routine is called with the task id.
> 4. Your crash routine notifies the user.
> 5. Your crash routine returns true/false to fail or continue.
>
> Just a thought!
I have an additional idea.
If a task crashes and nothing outside that task is affected, only that
task "dies", and all other tasks keep running. Is that possible?
Regards,
Juergen
--
Have you read a good program lately?
5. Re: Multitask Feedback
Hayden McKay wrote:
>
> I like the functions and concept of the new multitasking library. However I
> would like to see this remain as an optional only. I'm strongly against the
> idea of craming the Interpretor with stuff that would not get used on a day
> to day basis.
>
> P.S. I like it very much though.
>
I agree 100% !
I think there are many more important BASIC features that need to be
added to the interpeter before multitasking is added.
Bernie
My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.exw
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
6. Re: Multitask Feedback
Bernie Ryan wrote:
>
> Hayden McKay wrote:
> >
> > I like the functions and concept of the new multitasking library. However I
> > would like to see this remain as an optional only. I'm strongly against the
> > idea of craming the Interpretor with stuff that would not get used on a day
> > to day basis.
> >
> > P.S. I like it very much though.
> >
>
> I agree 100% !
> I think there are many more important BASIC features that need to be
> added to the interpeter before multitasking is added.
>
> Bernie
>
> My files in archive:
> w32engin.ew mixedlib.e eu_engin.e win32eru.exw
>
> Can be downloaded here:
> <a
> href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan">http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan</a>
>
I agree as well. I think Robert should just make these routines available in a
library. (Spice up sched.e and rename it to task.e or something) but dont
implement the API internally. It's not really important to me that there would'nt
be multiple call stacks, multiple private data, etc. I liked the idea of
cooperative tasking, only because I hoped Rob would eventually implement
"pre-emptive" thread safety or maybe just awareness later. But clearly he is not
going to. I think Rob should reconsider going with the "Language War" approach
before he messes with the C backend. Doing this will also make it easier for us
to add more features to the multi-tasking library.
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
7. Re: Multitask Feedback
> I think there are many more important BASIC features that need to be
> added to the interpeter before multitasking is added.
Strange, I was unaware we were programming in BASIC. All this time I
thought it was Euphoria.
~Greg
8. Re: Multitask Feedback
Hayden McKay wrote:
>
> I like the functions and concept of the new multitasking library. However I
> would like to see this remain as an optional only. I'm strongly against the
> idea of craming the Interpretor with stuff that would not get used on a day
> to day basis.
>
> P.S. I like it very much though.
>
I really like the code as well - it's simple to understand and implement
- a lot easier than a programme I wrote using two shells communicating
through memshare. As Rob says, it's a judgement call where it should be
implemented and such a call can only be made quantitatively.
It would be a shame to have its efficiency impaired if it wasn't built in.
Regards,
Bob
9. Re: Multitask Feedback
Juergen Luethje wrote:
> I have an additional idea.
> If a task crashes and nothing outside that task is affected, only that
> task "dies", and all other tasks keep running. Is that possible?
Maybe.
I'll give it some thought.
Thanks.
Currently when any task crashes you'll get a call stack
traceback in ex.err for *each* task, plus the global/local
variables as usual. The active (crashing) task info is listed first.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
10. Re: Multitask Feedback
------=_Part_13674_6926783.1127445823742
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I'll look into this soon, one of the main reasons I hardly code in Eu
anymore is because it didn't support multi-threading. I'd hate to see it's
speed effected if it wasn't built in, as it would really make it a moot
point for me having multi-threading if it was.
------=_Part_13674_6926783.1127445823742
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I'll look into this soon, one of the main reasons I hardly code in Eu anymo=
re is because it didn't support multi-threading. I'd hate to see it's speed=
effected if it wasn't built in, as it would really make it a moot point fo=
r me having multi-threading if it was.
<br>
------=_Part_13674_6926783.1127445823742--
