Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

timers in Core would be enough imo :-) (was) Re: Re: REBOL multithreadin

 [1/9] from: petr::krenzelok::trz::cz at: 14-Feb-2002 9:48


And face based mechanism actually can't be used in Core and Command - they both don't have face compositing engine. I don't remember correctly, if someone from RT already commented this here or not in the past .... it would be probably good to have general timers to move into Core language ....It would not be much of a problem to implement some kind of make-task then. We need either general timer! datatype, or just some kind of configurable scheme (open [scheme: 'timer rate: 0.001 awake: my-func]). Such port would then be put then in wait-list .... -pekr-

 [2/9] from: rotenca::telvia::it at: 14-Feb-2002 14:35

Re: timers in Core would be enough imo :-) (was) Re: Re: REBOL multithr


Hi, Petr
> And face based mechanism actually can't be used in Core and Command - they > both don't have face compositing engine. I don't remember correctly, if
<<quoted lines omitted: 4>>
> configurable scheme (open [scheme: 'timer rate: 0.001 awake: my-func]). > Such port would then be put then in wait-list ....
I do not think that multitasking can be easily done in Rebol for a reason: i could be wrong, but if you make a dispatch in the middle of a function and two tasks are executing the same function, the function's locals will be corrupted, because both the context and the function body would be shared between tasks. First, you must save locals of every functions (tree of calls), second you must rebind every body at every switch. An alternative is to use functions which duplicate their own bodies at every call, like Ladislav's e-func (if I remember well) else I think that the overhead would be too big for save+binding. --- Ciao Romano ----- Original Message ----- From: "Petr Krenzelok" <[petr--krenzelok--trz--cz]> To: <[rebol-list--rebol--com]> Sent: Thursday, February 14, 2002 9:48 AM Subject: [REBOL] timers in Core would be enough imo :-) (was) Re: Re: REBOL multithreading

 [3/9] from: lmecir:mbox:vol:cz at: 14-Feb-2002 16:05


Hi Romano, <<Romano>> ... An alternative is to use functions which duplicate their own bodies at every call, like Ladislav's e-func (if I remember well) ... <</Romano>> ...right, but it is called Cfunc now Regards Ladislav

 [4/9] from: greggirwin:mindspring at: 14-Feb-2002 12:21


Romano, et al << I do not think that multitasking can be easily done in Rebol for a reason: i could be wrong, but if you make a dispatch in the middle of a function and two tasks are executing the same function, the function's locals will be corrupted, because both the context and the function body would be shared between tasks...>> What about non-preemptive multitasking? Shouldn't that be possible? I freely admit total ignorance about the REBOL core design, which might make even that infeasible, and there would almost certainly be other issues releated to REBOL's dynamic nature, but it might be an alternate path worth investigating. --Gregg

 [5/9] from: carl::cybercraft::co::nz at: 15-Feb-2002 11:21

Re: timers in Core would be enough imo :-) (was) Re: Re: REBOL multithre


On 14-Feb-02, Petr Krenzelok wrote:
> And face based mechanism actually can't be used in Core and Command > - they both don't have face compositing engine. I don't remember
<<quoted lines omitted: 5>>
> 'timer rate: 0.001 awake: my-func]). Such port would then be put > then in wait-list ....
Holger (I think) said a long time ago that it would be possible to put multi-tasking/threading, or somesuch into REBOL but that it wasn't likely to happen soon. "Perhaps next year" I think he said, but which next year he was talking about I don't know. (: But if it's possible, we should get it one day I guess. -- Carl Read

 [6/9] from: chalz:earthlink at: 15-Feb-2002 1:30

Re: timers in Core would be enough imo :-) (was) Re: Re: REBOL multithr


Here's a quick (and probably ignorant) question: If threading isn't really possible with REBOL, how can you really construct a decent GUI, or server? I mean, serverware that can be listening to the port, receive a request, and deal with it, while another request is received, and so forth. Wouldn't this require threading? --Charles ----- Original Message ----- From: "Petr Krenzelok" <[petr--krenzelok--trz--cz]> To: <[rebol-list--rebol--com]> Sent: Thursday, February 14, 2002 3:48 AM Subject: [REBOL] timers in Core would be enough imo :-) (was) Re: Re: REBOL multithreading

 [7/9] from: petr:krenzelok:trz:cz at: 15-Feb-2002 10:06


Romano Paolo Tenca wrote:
> Hi, Petr > > And face based mechanism actually can't be used in Core and Command - they
<<quoted lines omitted: 15>>
> for > save+binding.
What about following? - kind of a state machine we can get with tcp communication: timer1: open [ scheme: 'timer rate: 0.01 locked: false awake: my-func par1 par2 ] my-func: func [par1 par2][ timer1/locked: true do-some-code timer1/locked: false ] insert wait-list timer1 So, my-func would be called only when timer1 would be in unlocked state, but still the timer could be checked each 0.01 period. It would allow us to run some background processing tasks ... But, I can be wrong here :-) Cheers, -pekr-

 [8/9] from: petr:krenzelok:trz:cz at: 15-Feb-2002 10:22


Charles wrote:
> Here's a quick (and probably ignorant) question: > If threading isn't really possible with REBOL,
noone said it isn't :-) In fact, Holger posted one long and very nice description of what are the possibilities and consequences of threading in regard to scripting languages ....
> how can you really > construct a decent GUI, or server? I mean, serverware that can be listening > to the port, receive a request, and deal with it, while another request is > received, and so forth. Wouldn't this require threading?
No :-) Do we have threading? Can you see your View scripts to block you? As with tcp, when you open your listen port, you can open it in no-wait mode. In this case wait [portX] checks for data on your portX, but returns imediatelly, either telling you there is no data, or returning you port (or block of ports if wait/all is used) some data appeared on .... You can receive your data in parts, process them and return back to waiting. You can look at some web-server or proxy scripts in the script library for some examples .... -pekr-

 [9/9] from: rotenca::telvia::it at: 15-Feb-2002 15:38

Re: timers in Core would be enough imo :-) (was) Re: Re: REBOL multith


Hi Petr,
> No :-) Do we have threading? Can you see your View scripts to block you? As
with
> tcp, when you open your listen port, you can open it in no-wait mode. In
this
> case wait [portX] checks for data on your portX, but returns imediatelly,
either
> telling you there is no data, or returning you port (or block of ports if > wait/all is used) some data appeared on .... > You can receive your data in parts, process them and return back to waiting.
You
> can look at some web-server or proxy scripts in the script library for some > examples ....
Do you know what ports permit waiting beyond tcp and tcp based? Or it is the only one (togheter event, of course)? Can be created by user a new protocol for no-wait port? --- Ciao Romano

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted