![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <40d0df06$1@news.povray.org> , "Michael Raiford"
<mra### [at] hotmail com> wrote:
> I'm
> betting that somewhere in the parsing code, when it's cancelled, or an error
> occurs it doesn't always close the file.
That bet you will loose! It simply happens in two threads.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich wrote:
>
> That bet you will loose! It simply happens in two threads.
>
> Thorsten
More detail? Is it a thread sync issue then?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich wrote:
>
> That bet you will loose! It simply happens in two threads.
>
> Thorsten
More detail? Is it a thread sync issue then?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <40d6dd18$1@news.povray.org> , Mike Raiford
<mra### [at] hotmail com> wrote:
>> That bet you will loose! It simply happens in two threads.
>>
>> Thorsten
>
> More detail? Is it a thread sync issue then?
Yes, as the render core and the frontend got decoubled in 3.6 it is possible
that if a system insists on not writing to files open for reading it will
protest. Most systems do not have such a problem by default, Windows is
fairly unique in this respect...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Darren New wrote:
| Thorsten Froehlich wrote:
|
|> Most systems do not have such a problem by default,
|
|
| Actually, most *do*, except for UNIX-based systems. I've never seen
any
| other system where the default for opening a file for reading was
to not
| block writers and vica versa.
|
Windows 2000 :) In fact I've even been able to have two completely
distinct processes open the same file for writing simultaneously
using the standard library calls (well actually I'm using C++
ofstreams) with no particular options. That didn't work when I was on
Win98 though...
Jerome
- --
******************************
* Jerome M. Berger *
* mailto:jbe### [at] ifrance com *
* http://jeberger.free.fr/ *
******************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2fWfqIYJdJhyixIRAtKNAJ9Ncwf30/ZAWhn95gPfj6RdI9JKxwCdFHHQ
AdfXRGtlIylg8IV1361FTaY=
=kGis
-----END PGP SIGNATURE-----
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
While the discussion of threaded execution on different platforms is
interesting in its own right, I have a more pragmatic question: Is there
any hope that this behavior will be fixed in the short term? And if not,
does anyone have a workaround that is less cumbersome than using Save As
with a different name, dropping out of POV-Ray, restarting, and using Save
As to replace the actual file with the correct copy?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"gilroy" <nomail@nomail> wrote in message
news:web.40fb3bdb67e770e41ca8af40@news.povray.org...
> While the discussion of threaded execution on different platforms is
> interesting in its own right, I have a more pragmatic question: Is there
> any hope that this behavior will be fixed in the short term? And if not,
unless I can reproduce it then it's unlikely to be fixed.
if you can send me a scene file that will reliably cause the error on W2K or XP
then I can find the cause.
-- Chris
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
gilroy wrote:
> While the discussion of threaded execution on different platforms is
> interesting in its own right, I have a more pragmatic question: Is there
> any hope that this behavior will be fixed in the short term? And if not,
> does anyone have a workaround that is less cumbersome than using Save As
> with a different name, dropping out of POV-Ray, restarting, and using Save
> As to replace the actual file with the correct copy?
I do have a half-way solution that has actually worked for me in the
past when this comes up:
Go to www.sysinternals.com, download process explorer. Open it up and
search for the file handle, Kill the handle that POV-Ray has held open
(your file...) save the file and continue.
Standard disclaimer: I am not responsible for crashes as a result of
this solution. YMMV. etc, etc etc...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Cason wrote:
> unless I can reproduce it then it's unlikely to be fixed.
>
> if you can send me a scene file that will reliably cause the error on W2K or XP
> then I can find the cause.
>
> -- Chris
Hmm. Half the problem is it happens in a completely non-deterministic
fashion. The only thing you can hope to do is add some basic thread
synchronisation to the code that deals with the file handle, From what I
have experienced, there is no single way to cause this problem to
reproduce.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Michael Raiford <mra### [at] hotmail com> wrote:
> Chris Cason wrote:
>
>
> > unless I can reproduce it then it's unlikely to be fixed.
> >
> > if you can send me a scene file that will reliably cause the error on W2K or XP
> > then I can find the cause.
> >
> > -- Chris
>
> Hmm. Half the problem is it happens in a completely non-deterministic
> fashion. The only thing you can hope to do is add some basic thread
> synchronisation to the code that deals with the file handle, From what I
> have experienced, there is no single way to cause this problem to
> reproduce.
That's my experience, too. It seems to arise most reliabily if there's a
parse error when there's a main scene file calling macros in an include
file -- but I can't say if that's really a symptom, or if it's just that
most of my code lives in other files.
Sometimes it just happens -- even if the parse is over and had no errors.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |