"George Peter Staplin" <georgepsSPAMMENOT@[EMAIL PROTECTED]
> wrote in message
news:fjgest$46m$1@[EMAIL PROTECTED]
> cr88192 wrote:
>> request:
>> general opinions with regards to sup****ting concurrency within a C
>> compiler.
>>
<snip>
>
> I propose Box programming. I wrote a paper about it here, although I
> used a language called Tcl for the implementation:
> http://www.xmission.com/~georgeps/do***entation/software/TFP5.pdf
>
> Here's an example of several fictional boxes that form a process
> network:
>
> box sender {
> /* startup code for sender */
> } takes (struct boxobj *addr, struct boxobj *data) {
> /* addr could be a NUL-terminated string with a size_t for length */
> if (sendsomehow (addr, data)) {
> out 0 (FAILURE);
> } else {
> out 0 (SUCCESS);
> }
> } out 1 /* this has 1 output ****t */
>
>
> box input {
> /* startup code for input */
> FILE *fp = stdin;
> } takes (void) {
> out 0 (readinput(fp)); /* read an addr */
> out 1 (readinput(fp)); /* read data */
> } out 2
>
>
> box logger {
> FILE *fp = fopen ("log", "a");
> if (NULL == fp) {
> perror ("fopen");
> exit (EXIT_FAILURE);
> }
> } takes (struct boxobj *msg) {
> writeobj (fp, msg); /* write our log message */
> } out 0
>
>
> int main (int argc, char *argv[]) {
> connect input 0 sender 0
> connect input 1 sender 1
> connect sender 0 logger 0
>
> while (n processes are running) {
> route ();
> }
>
> return EXIT_SUCCESS;
> }
>
>
> Ideally none of the processes in the network know about their
> connections. Also, it should be possible to dynamically alter
> connections in the router. Thus a disconnect keyword might be useful.
>
>
> In practice I think parts can be implemented somewhat ****tably with
> pipe() and CreatePipe() for the respective systems. The startup code is
> another matter though. I'm not sure how to implement the startup code
> for each box ****tably, unless the compiler outputs several executable
> images. POSIX is somewhat easier...
>
> I hope this helps.
>
interesting idea, but likely to be a little alien in C land.
not like I can claim my idea is much less so:
foo!(2, 3);
(leading to a function call where, unless it is joined, one has almost no
idea when it will actually happen...).
yeah...
actually, one idea I had considered was the possibility of "message pipes"
(I had these in a few of my previous languages). the problem with C being
its inflexibility in some matters (otherwise, I would have to do something
"creative").
of course, sending structs over pipes would be easy, but the hope is not
to
send structs, but actual tuples of some sort.
then again, one can implement message pipes (in a plain struct-passing
manner) purely as a library facility, which may be worth consideration
(this
would be, sort of like MPI, but representing a system of interconnected
nodes and message pipes, rather than some flat list of well-defined
threads
passing buffers around).
another simple, and interesting, idea, would be implementing something
along
the lines of Linda, but I am not so sure how useful this would be...
these would be used in combination with more traditional approaches (aka:
good old threads and mutexes...).
it seems the whole problem is even less clean-cut than I had originally
thought...
> George
|
