I will apologize for the response length up front.

> Here is my thinking. I think if we can go with the programs being 9p
> servers, and communicating via the kernel via files, you can show your
> community a very new way to structure these types of applications,
> which would provide a degree of security (isolation) they have never
> seen before, as well as a degree of flexibility that would be neat,
> and, finally, support really easy distributed computing.

Setting them up as 9p servers is where I was hoping to go, but being new
to Plan 9 I am not sure where exactly the boundaries between Native Plan 9,
9vx, plan9port, and P9FS (or P2000) are.  Can 9p servers be set up in
plan9port, or use 9vx or other Plan 9 emulators?

With this as a starting point I am going back to nemo's materials/books
and focusing on /srv/echo and plumbing.  Can you recommend specific
URL's/examples I should focus on in my study?

> ... Checkpoint is a file, which when read, provides a
> checkpoint -- not of the whole program, just the state that the
> program *needs* to have saved if it wants to restart (that's a very
> important distinction).

Having checkpoints would be a HUGE godsend!  Dealing with this has been a
nagging issues in the back of my mind which I was going to put off til
later, but COOL!!!

Another discussion I would like to address at a later date is resiliency
-- detecting a dead node and recovering/restarting.

> This approach allows programs to export their "guts" as files. It's
> something new. I suspect it will be very new to your community.

I think this is similar to how I first implemented HPD by registering
variables and requesting through a dispatch mechanism.  Plan 9 is a MUCH
better way because the old implementation requires changing the programs to
register variables.  Here they basically all know how to deal with the
exported info.

> I think if you go the traditional dlopen() route, there's no real
> value add over Linux that I can see, and the end question remains: why
> are we doing this? Because if we're not using something special from
> Plan 9, there actually is no real advantage: no real fortran compiler,
> for example.

I know mentioning fortran would come back to bite me ;-)  If I *really*
need it I will play with porting f2c if it has not already been done. 
Fortunately many of the modeling groups are moving from fortran to c/c++,
so that is being a mute point.

I think in retrospect that most of my confusion resulted from not having a
clear distinction of what functionality is implemented in
Plan9/9vs/plan9port, and getting distracted by the whole threading/locking
issue.

Thanks and best regards,

  EBo --

-- 
You received this message because you are subscribed to the Google Groups "Plan 
9 Google Summer of Code" group.
To post to this group, send email to plan9-g...@googlegroups.com.
To unsubscribe from this group, send email to 
plan9-gsoc+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/plan9-gsoc?hl=en.

Reply via email to