World: r3wp

Start by providing the __attribute__ for thread-locals, assuming 
that the .so supports that.  If not, we'll need to move the thread 
local vars into a struct, and allocate it dynamically.  However, 
we'll still need at least one thread-local from the host kit side, 
to provide the base pointer for each thread.

Carl - you said:


The model is: threaded CPU, shared memory, shared symbol space, shared 
system function space, separate evaluation stacks, separate user 
contexts.


Intertask comm is via Ports. Sync is via ports. BTW, "ports" does 
not need to mean "sockets".

Does it mean the code is in the Host, not in the kernel?

Yes, most of the work is in the Host.

However, the kernel uses thread-local variables.... which are not 
currently enabled on Posix builds.

without task!, Doc can't start moving Cheyenne (our premium product) 
to R3. He recently added early support for websockets protocol ....

Pekr, I'm not so sure that's true.

The only advantage of task! is about 1MB of memory. Otherwise, you 
can fire up multiple R3 processes and communicate between them.

We have the old R2 IPC code here that we could use for quick messages 
between procs.

I know what you mean. It could be ported, but model would be the 
same as in R2 - multiplexing, spawned tasks. But I think Doc might 
be interested in using threads instead, so my bet is he will wait, 
until it gets finished ...

Yes, I think that ppl expect task having some schemes around them, 
to allow IPC. IMO what was wrong with R2 was, that we (as a community 
plus RT) never "standardised" on such things ...

Of course, the other benefit is that in sharing symbols, we could 
pass full blocks (not text) between task!s.

So most ppl (let's say average coders) ended up with the possibility 
to spawn new R2 processes, but not knowing how to properly sync them 
to communicate ...

Well, I'd like to see a lot more standards in R3. At least, I'm planning 
a few std modules for all the common stuff we use here.

I think that many ppl here think that the priority of importance 
is:

- host release
- host support of View (merge of DELECT and command type)
- Extensions supporting Devices, callbacks
- tasking, IPC
then beta ....


If you postpone anything from above to 3.1, some ppl will wait for 
3.1 ... do you want to bet with me? :-)

I think you are correct. But, as soon as we are confident in 3.0, 
we should put it out, even if missing a few features.

For example, the new REBOL.com website runs on R3 scripts.

I am fully for R3, and to not look back. Did you notice, how positive 
reactions you got to initial Host release? Hopefully that cooperative 
aproach works. But in some areas, we NEED design leadership. So - 
that is why I put a note to my "marketing" related docs, stating 
that simply transferring the responsibility to the community, might 
not see the features delivered.


So - maybe you could blog a bit - hey, guys, tasking's next. If you 
want it, try to prepera following details for me .... 1) 2) 3), etc.

I totally agree with you here.  In fact, I won't accept anything 
that does not meet my requirements.

yes, so hopefully you can now understand, why I objected to your 
(taken from Project plan) words: "Also, this list is only for R3 
core operation and does not include community-based projects such 
as graphics, GUI, protocols, documentation, and other features that 
can be developed externally, depending on the needs of the community."

I can (well, maybe I even can't :-) imagine, how picky you might 
be about the code quality. So it is really not imo enought to state 
- hey, guys, here's host code, who does the best task implementation, 
wins a bottle of Rebol wine :-)

I know that BrianH might not agree with me. Community can do some 
research, reference implementation, but I would expect stuff like 
tasks being DESIGNED (not implemented) by the author of first multitasking 
operating system himself :-)

OK, going to sleep, 2:30 here ... and soon enough Doc might jump 
here, that I turned his group off-topic ...

Steeve seemed to imply that R3 has its own thread scheduler. Is that 
true?

No.

I thought so :-)

I think he's referring to the R3 Device timeslicer.

Is that based on async I/O or something?

Yes.

But not all devices are async.

So, if no devices have "work to do" then we sleep for a short period 
of time (as long as that period is greater than the minimum dispatch 
time for the host CPU.)

We have more adjustments to make on this. E.g. OS X burns extra CPU.

I thought Henrik would have it fixed by now. ;-)

Ah, I remember that. Good info

Carl, I'm not a C programmer, so I can't fix that stuff. :-)

@doc: is there macos version of cheyenne?

Endo, I run Cheyenne off my macbook, script version, though. Runs 
fine.

Thx. Does not it require be compiled? Console should be stay open 
I guess, there is no service edition on MacOS?

No compilation necessary. Services are builtin: launchd

I use Lingon to create services and then use the launchd console 
to load and manage services.

Ok. Thanks a lot.

Endo: you can run it on OS X either from sources or using a binary 
version from here : http://cheyenne-server.org/download.shtml

Doc: is this the session-problem fixed version? or it was only a 
windows related problem?

Btw, I wrote a "intranet voting system" using cheyenne & rsp just 
in 2-3 hours (with login, user management, messaging, voting, product 
upload etc.). That was a real fun to use rsp.

session-problem

: if you mean the issue raised by Janko and fixed a few days ago, 
it's in the SVN repository: http://code.google.com/p/cheyenne-server/

Intranet voting in RSP: "simple things should be simple to do." ;-)

Doc: yes, I meant that, you sent me the fixed version r40.

Right, I forgot...

Anyone know if RT is looking at using Cheyenne on the backend?

Also, is Cheyenne currently being ported to R3?

1) Don't know.
2) No, see yesterday's discussions here.