I think I know exactly how you feel. as an example, liquid, one of my brainchilds took a lot of time to mature (and its about to undergo a new round of refinemnet). It exists, and was shared and is available to anyone who asks for it (its now in slim format, just not yet released)...
liquid is really usefull, if you "get" it. Yet was it worth the "release" effort... I still don't know... I didn't get much feedback. I don't even know if anyone else is using it... probably not. so as for your tool. as much as I'd like to say to python users that I can thread executions of scripts (and do it better than them, cause they can't remotely kill threads), at this point, I wonder how many tools really need that functionality. Who writes servers in rebol... not many of us... How many people even use threads in python... not that whole lot either. I've had to, they (threads) are usefull, but with rebol's smaller user base... even if 1% of us used(needs) it, you'd still have a handfull of users, and many would use it just to see if it works... and if it goes 400% slower... not sure that's fit for server usage in all circumstances... maybe someone who wants to create a networked front-end for RebDB might want to introduce threading... but will it help go faster in the end, if all threads run on one cpu (even in a multi-cpu machine...). Tough question indeed. I hope you get people which can give you a definite yes, giving you some push towards putting time on it. It looks like a fun challenge you want to put yourself against. :-) cheers! -MAx --- "You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun." > -----Original Message----- > From: Maarten Koopmans [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 29, 2004 12:42 PM > To: [EMAIL PROTECTED] > Subject: [REBOL] Re: Threading continued > > > > Yes, I can do all that (although it is good somebody reminds > me of it ;-))) > > But is it worth the effort? > > --Maarten > > Maxim Olivier-Adlhoch wrote: > > >good question, > > > >can you guarantee that one crashing thread (just an > evaluation error) can never stop execution of the other > threads, and allow some sort of signals to warn you that a > thread has dumped? > > > >Allowing you to respawn it? > > > > > >-MAx > >--- > >"You can either be part of the problem or part of the > solution, but in the end, being part of the problem is much more fun." > > > > > > > > > >>-----Original Message----- > >>From: Maarten Koopmans [mailto:[EMAIL PROTECTED] > >>Sent: Thursday, January 29, 2004 11:05 AM > >>To: [EMAIL PROTECTED] > >>Subject: [REBOL] Threading continued > >> > >> > >> > >>Hi, > >> > >>I have got some code and some questions. I have a working > version of > >>'eval a function that takes a block of code and evaluates > it like 'do. > >>Big deal? Well... it responds to a 'rest word, giving you the > >>restof the > >>block to be evaluated and the value of the last evaluated > expression. > >> > >>So: eval [ 10 + 10 join "a" "b" rest 20 print "howdy" ] > >> >> [ "ab" [ 20 print "howdy"]] > >> > >>Note that the second item (the rest of the code) is the > >>position in the > >>original code, so a ' head on that gives you the original code back. > >> > >>Anyway.... this interruptable evaluator run on a block with > >>10.000 now > >>invocations 3.5 times slower than do. That's slow, but > probably fast > >>enough for most things. And Moore's law and all... > >> > >>On top of such an eval function you can easily build a co-op > >>threading > >>engine. Instead of doing a script you would 'eval it, > making it four > >>times slower but concurrent. > >>And it would be easy to add all sort of utility threads > >>out-of-the box > >>for newbies, like a dns reader thread that returns the value to a > >>function on completion etc. > >> > >>Question: is this a thing any of you want despite the > >>performance hit of > >>400% ? > >> > >>It is easy for me to get there, but I need to know if there > >>is anybody > >>who'd like to see it available. > >> > >>Thanks, > >> > >>Maarten > >>-- > >>To unsubscribe from this list, just send an email to > >>[EMAIL PROTECTED] with unsubscribe as the subject. > >> > >> > >> > >> > > > > > > > > -- > To unsubscribe from this list, just send an email to > [EMAIL PROTECTED] with unsubscribe as the subject. > > -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
