|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been thinking about how to support distributed
rendering with POV, without having to introduce
any platform specific code. What I have at the
moment is a Mutex implementation, based on
a lock file.
Imagine a LAN with a common filesystem, and
povray running on different machines. Each
povray looks in the same directory for INI
files, a queue of jobs for the network.
There needs to be a mechanism to stop two
or more povray's grabbing the same INI.
What I have at the moment is a lock file
that is owned by only one process at a time.
The implementation is attached to the end
of this post. The basic idea is to use
the remove() standard ANSI C function to
test if any other process has a lock on the
resource. It will also fail in the situation
where another process has removed the file,
but hasn't yet replaced it.
It works in Windows NT, I'm going to try it
on Linux.... But does anyone have a general
impression whether this is going to work
across network filesystems: Windows, Novell,
NFS?
Also, is there a tider way to do this?
A weakness in the algorithm is that if
the file is missing, no process will be
able to lock the resource. Therefore,
I'm not happy with the robustness of
this particular algorithm.
----
FILE *lockFile = NULL;
void unlock()
{
if (lockFile)
fclose(lockFile);
}
void lockDir(const char *dir)
{
char filename[MAXPATH];
sprintf(filename,"%s/lock.tmp",dir);
unlock();
while (remove(filename)!=0)
Wait(2);
lockFile = fopen(filename,"w");
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
>
><...>
>
> It works in Windows NT, I'm going to try it
> on Linux.... But does anyone have a general
> impression whether this is going to work
> across network filesystems: Windows, Novell,
> NFS?
Synchronization over NFS is a tricky subject. I am by far no expert, but
I remember several issues with NFS. And synch was one of those.
>
> Also, is there a tider way to do this?
> A weakness in the algorithm is that if
> the file is missing, no process will be
> able to lock the resource. Therefore,
> I'm not happy with the robustness of
> this particular algorithm.
>
The most important point is, that it propably scales not well enough. It
may scale better than the pvm approach, because you have a star as
topology, but the load on the server will be pretty high pretty soon.
My idea would be to really develop a distributed rendering model, with
hand tuned topology, e.g. a tree.
I will eventually look at this, but currently I am in compiling almost
everything else but povray. (XFree was yesterday, next is gnome)
Axel
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Synchronization over NFS is a tricky subject. I am by far no expert, but
> I remember several issues with NFS. And synch was one of those.
The question can be posed simply: If a file is open for
writing by at least one program, does NFS prevent that
file from being deleted? This is the behaviour I'm trying
to exploit. Linux seems to enforce this for normal
(ext2fs) filesystems...
> The most important point is, that it propably scales not well enough.
> It may scale better than the pvm approach, because you have a star as
> topology, but the load on the server will be pretty high pretty soon.
That's an important point, but what I have in mind is
something small-scale that can act as a basis for
something more sophisticated. It should be possible
to distribute between (shared file-system) networks,
but this involves more in the way of transferring
files around. I think the lower level could be solved
in a simple, portable way... A filesystem interface
to POVray is about as generic as I can think of... :-)
My broader aim is something suitable for distributed
rendering across the Internet, in a distributed.com
kindof fashion, but I think something that works
on a LAN would also be pretty useful. (and funky)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
>
> > Synchronization over NFS is a tricky subject. I am by far no expert, but
> > I remember several issues with NFS. And synch was one of those.
>
> The question can be posed simply: If a file is open for
> writing by at least one program, does NFS prevent that
> file from being deleted? This is the behaviour I'm trying
> to exploit. Linux seems to enforce this for normal
> (ext2fs) filesystems...
>
This should be, but the mess starts, when two process try to lock at the
same time. And the stability of nfs daemons is something varying.
> > The most important point is, that it propably scales not well enough.
> > It may scale better than the pvm approach, because you have a star as
> > topology, but the load on the server will be pretty high pretty soon.
>
> That's an important point, but what I have in mind is
> something small-scale that can act as a basis for
> something more sophisticated. It should be possible
> to distribute between (shared file-system) networks,
> but this involves more in the way of transferring
> files around. I think the lower level could be solved
> in a simple, portable way... A filesystem interface
> to POVray is about as generic as I can think of... :-)
>
> My broader aim is something suitable for distributed
> rendering across the Internet, in a distributed.com
> kindof fashion, but I think something that works
> on a LAN would also be pretty useful. (and funky)
It is. And there are quite some folks that have something like this
around. I don't have anything handy but the pvm-stuff. As this is
digging the source, it's a bit out of your scope I think. But there is a
distpov or something. There are alot questions about this in this
groups, just search for it. It's still not in the vfaq :-(
Axel
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > The question can be posed simply: If a file is open for
> > writing by at least one program, does NFS prevent that
> > file from being deleted?
>
> This should be, but the mess starts, when two process try to lock at the
> same time. And the stability of nfs daemons is something varying.
Seems that this could be boiled down to a simple program
that can hammer away at a filesystem relentlessly, to
test the "sequentiality" of the protocol. I figure that
if two processes try to delete the same file, one of them
MUST fail. (Assuming that the file exists, and nothing
has a lock on it)
> It is. And there are quite some folks that have something like this
> around. I don't have anything handy but the pvm-stuff. As this is
> digging the source, it's a bit out of your scope I think.
You're right - I should check out other projects in this
direction. But I think this question is quite pertinent
to POVray, since it implies that a clustered render-farming
solution for POVray could be bolted onto the next official
release, quite cheaply. No PVM, no big design effort, just
a simple model for small networks... ...that also fits
larger scale efforts....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|