home *** CD-ROM | disk | FTP | other *** search
- Organization: Carnegie Mellon, Pittsburgh, PA
- Path: sparky!uunet!wupost!udel!rochester!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!<UNAUTHENTICATED>+
- Newsgroups: comp.sys.isis
- Message-ID: <seS3w2_00hMg97SEU5@cs.cmu.edu>
- Date: Thu, 30 Jul 1992 15:12:02 -0400
- From: Sean.Levy@cs.cmu.edu
- Subject: task arguments
- Lines: 38
-
- The man page for isis_entry(3) in ISIS 2.2/3.0.5 implies that you can
- associate an argument with a task (e.g. a closure). However, it does not
- say any more about it other than the rather cryptic usage info:
-
- ...
- SYNOPSIS
-
- int isis_task(task,name)
- int isis_entry(entry,handler/MSG_ENQUEUE,name)
- void (*task)(arg)
- void *arg;
- ....
-
- The code does not look like it does anything of the sort, e.g. tasks
- don't get arguments. Is this something that used to be in the code and
- was deleted, something that is coming, or just a typo? I'm trying to
- write a generic Tcl interface to ISIS, and closures for tasks are really
- needful; I can fake it with a static linked list, but I dislike such
- solutions on principle (plus they always end up biting you on the butt
- later on if you move to a real multiprocessor).
-
- In general, I would like to see any sort of indirect function calls
- anywhere in the system always be accompanied by closures, however and
- wherever they are, ala Tk, Xt, and other toolkits for even-driven
- environments. It makes life much easier, and you burn at most the size
- of a pointer per indirect function, which isn't too bad when you
- consider what you gain.
-
- Just my $0.02. Of course, if I'm wrong and there is a way to do this,
- please let me know. I *still* think ISIS is the best thing since sliced
- bread for building distributed systems (there, now can I get my coffee
- mug?? :-)
-
- Cheers,
- -- Sean
- --
- Sean Levy, n-dim Group, EDRC, CMU, 5000 Forbes Ave, PGH, PA 15213
- Email: snl+@cmu.edu, Phone: +1 412 268 5221, Fax: +1 412 268 5229
-