From: David Thompson <dcthomp@sa...> - 2002-08-29 20:33:24
Since the list seems to be quiet, I'll post some of the
wishlist items that came out of the meeting.
1. Job termination
It sounded like we've agreed that the crservers should keep
an open TCP/IP connection to the mothership over which
some apoptosis signal would be sent when the application
exited. In order for the mothership to know when to send
this signal, it probably means the application nodes will
have to keep an open line to the mothership as well.
There was also some talk of having the mothership report
application death to any surviving application nodes so
that parallel jobs could decide to continue or die.
2. Multiple motherships
I'd like to see multiple mothership supprt in Chromium.
Multiple motherships require mothership.py to keep opening
different ports until it finds one that's not bound.
The resulting port number must be used by the servers
and application processes.
CR.Go() needs to be broken into two routines for
job autostarting to work with multiple motherships
because config scripts may need to set the CRMOTHERSHIP
environment variable in a CRNode.Autostart() call, which
must be made before CR.Go().
Also, I'm not too clear on whether crservers attempt
to open another port if the one they're assigned by the
mothership is bound. If not, implementing that and
relaying the resulting port number back to the mothership
will also be necessary.
3. Application Hints
Randy wants a mechanism for applications to provide
hints to the mothership about suitable configurations.
The idea is that
- if the application has some knowledge of how it
should be configured it could call glChromiumParameterv
before creating a context to provide a hint (such
as "Sort First Only" or "No Packers") to the mothership,
which would check SPU chain and reply, or
- if an environment variable (CRAPPROPOS, for example)
was set, StubInit would call glChromiumParameterv for
the application and exit if the test failed.
This way, (l)users would not be allowed to run applications
on SPU chains that would guarantee poor performance (and
thus poor impressions).
Any other wishes for the application environment? Any complaints
about what's here?