r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Pekr
15-Jan-2007
[6649]
Gabriele - so what is "tasking" in R3 going to be under the hood? 
There were various things said - 1) we will have something like make 
task! syntax, which will use OS threads in the background, just hiding 
the complexity of threading model from user (= simplicity in rebol 
level) 2) In one of recent blogs and their comments Carl said he 
might have its own way of how to do tasking in Rebol. So, how will 
it look? Is it already decided?
Gabriele
15-Jan-2007
[6650]
what you describe above, can be easily obtained by doing the dns 
resolution in one task. what you see is a port, that to you looks 
exactly like an async dns port. except that it is implemented in 
mezz code rather than being native.
Pekr
15-Jan-2007
[6651]
Gabriele - so you already partially answered my question - OS threads 
in the low level, but from the user pov it will be abstracted by 
eg. make task! syntax plus port model?
Gabriele
15-Jan-2007
[6652x2]
that is, from your point of view it could look exactly like the async 
core.
exactly.
Pekr
15-Jan-2007
[6654x2]
Gabriele - we have async dns already, don't we? dns:/// .... but 
what is currently blocking without ability to set timeout is trying 
to establish a connection (SYN) ... or can we make it also a non-blocking?
If there is a way of how to do fully non-blocking communication, 
as for me, I don't need async ... if I need "async" behavior, I might 
use rebol tasks ....
Gabriele
15-Jan-2007
[6656x3]
hmm, you can make connections asynchronously
eg. when you make a connection with async:// or atcp:// there is 
no wait involved
the point rather is, than normally, instead of delving into the complexity 
of an asynchronous event based interface, you just make a task and 
use read.
Pekr
15-Jan-2007
[6659]
ah. But was it possible with old cores? IIRC Holger explained that 
we can't influence connection ... if it was corrected, it should 
be satisfactory ...
Gabriele
15-Jan-2007
[6660]
i haven't done measurements accurate enough to tell you if there's 
some little blocking somewhere. but in practice i don't see any blocking 
with current core and async tcp
Pekr
15-Jan-2007
[6661]
Gabriele - correct - after all - what we want from REBOL is - provide 
simplicity in user level. Not all users can think in complex async 
way ....
Gabriele
15-Jan-2007
[6662]
in principle, you could implement this, in native code, by using 
the async core and implementing tasks over that.
Pekr
15-Jan-2007
[6663]
Gabriele - what was the reason Chord was not successfull in Rebol? 
IIRC you said it is difficult to achieve with current kernel. Why? 
If we have fully non blocking kernel, should there be any problem?
Gabriele
15-Jan-2007
[6664x2]
however, that would have the big disadvantage, of not making use 
of multiple processors if they are present.
also, it's probably harder to do, when the os already provides threading, 
and the os libs are good with threading but not with your system.
Pekr
15-Jan-2007
[6666]
hmm, that is interesting situation indeed. First we thought of parralelism 
as multiple CPUs in the system. Now the trend is to place multiple 
CPU cores in one CPU. I wonder if we can influence, what task/thread 
in OS uses what Core? Is there any API, or CPU decides on its own?
Gabriele
15-Jan-2007
[6667x2]
Chord - problem number one, udp:// has bugs that make it inusable 
in async manner. problem number two, it just stopped working after 
a couple minutes, and figuring out why was incredibly difficult. 
(maybe it'd work on 1.3... but i haven't had time to try it)
i think the os decides how threads/processes are scheduled.
Pekr
15-Jan-2007
[6669]
udp has bugs? Why not fix them then? :-)
Gabriele
15-Jan-2007
[6670x2]
they are on rambo.
they will probably be fixed someday :)
Pekr
15-Jan-2007
[6672x2]
as for R3 - networking layer is the one ported from 2.x, just plugged 
into tasking/threading model, or is it new implementation? (IIRC 
Carl said port model is going to be a bit reimplemented?)
re "fixed someday" - I thought that it is essential in regards to 
networking communication language to adhere to communication standards 
and protocol behaviour :-)
Gabriele
15-Jan-2007
[6674x2]
i would guess it is a new implementation. there are two reasons it 
must be: the os code has to be separate, and the internal model is 
probably very different.
well, udp works, as long as you don't try to use it in a 100% async 
manner.
Pekr
15-Jan-2007
[6676]
ok, thanks for your answers - looking forward to R3 Core alpha, hopefully 
released at least for DevCon time :-)
Gabriele
15-Jan-2007
[6677]
probably noone except me used it that way, so noone except me complained 
about the bugs in udp (i think there was another person at least... 
but we're just two)
Pekr
15-Jan-2007
[6678]
my first tests will be amiga one - generating 10K processes and looking 
how system is stable :-) Amiga was very OK with such tests once you 
had enough memory :-)
Gabriele
15-Jan-2007
[6679]
that might not kill rebol, but it might kill windows. ;)
Pekr
15-Jan-2007
[6680x3]
hehe, exactly :-)
but it will be interesting comparison too - for apache, there is 
some "standard" testing tool done in perl, measuring its performance. 
We should try two models and compare - having rebol http server, 
first using non-blocking io multiplexing, one task, second generating 
new thread for each connection - measure response, amount of memory 
consumed etc ....
going to lunch, thanks for the chat ...
Gabriele
15-Jan-2007
[6683]
it really depends on what you are going to do with the connection. 
one thread for 10 connections might be better in some cases. :)
Joe
15-Jan-2007
[6684]
pekr,  async DNS is not really "async" , it is non-blocking
Pekr
15-Jan-2007
[6685]
Joe - yes, that is how I understand it ... now how is rebol trying 
to establish a connection non-blocking? Can I set kind of timeout? 
hmm, maybe I will have to look into async:// protocol ...
Joe
15-Jan-2007
[6686]
there is a great lack of information from RT !  The problem is core 
is still widely propietary and it is imposible to find out how things 
like async DNS work without RT publishing the info. I was interested 
in writing an async DNS using Gabriele's async as a reference but 
I now find that udp has bugs ! Another surprise to discourage me 
!
Pekr
15-Jan-2007
[6687]
Gabriele stated UDP has bugs in some heavy scenarios. Maybe you will 
not experience such problems. But I do agree that bugs should be 
fixed. Now the question is, if it should happen for R2, because R3 
will have different networking or so I think ...
CharlesS
15-Jan-2007
[6688]
argh cant wait for R3, going to be exciting
Ladislav
16-Jan-2007
[6689]
as far as I know 1/1/0000 is the smallest possible date! value in 
REBOL. Taking that into account, what do you expect the expression 
1/1/0000 - 1 to do?
PeterWood
16-Jan-2007
[6690]
At the risk of moving the chit-chat conversion here, shouldn't  the 
result be 1 BC?


Perhaps  -1 would be an appropriate result to signify one year before 
the year zero rather than the year 65535 as at the moment.
Oldes
16-Jan-2007
[6691]
Forbidden access into history error?
PeterWood
16-Jan-2007
[6692]
Personally, I think that processing BC dates is slightly less banal 
than dates after the year 32677.
Oldes
16-Jan-2007
[6693]
I don't think if it's too important, if you are making history application, 
you should be awared of such a issues. But error would be probably 
better than this.
Volker
16-Jan-2007
[6694]
regarding chit-chat, then you  need dates going  back at least  6k 
years, maybe even some billion!^^

regarding  bc,you have to figureoutwhen the  calendars changed. Andhaveto 
 agreewhich calendars to  use^^
Henrik
16-Jan-2007
[6695]
astronomical applications might need to go into extremes with date 
handling. I think Geomol would know about this more than me. :-)
Rebolek
16-Jan-2007
[6696]
astronomical application would use Julian date anyway I think :)
Geomol
16-Jan-2007
[6697x2]
Date handling is difficult! :-) The UNIX command "cal" handle the 
switch from Julian to Gregorian Calendar in 1752. If you have access 
to UNIX, try:
cal 1752

and look at September. Henrik, I'm not sure, what astronomical applications 
do, but I guess, we can look it up.
AFAIK, REBOL can't handle the calendar switch.