this is the kind of problem that i was predicting a couple weeks back.
with the  "temp files" post

i think we should replace all tmpnam() calls with tmpfile() -- at least 
this
would prevent multiple users and/or multiple processes trying to create 
the
same file.  if it is true that a 'regular' user cant create files in 
/tmp anyway
on OSX then i will have to have it write the files somewhere in user's 
space..

-m

Begin forwarded message:

> From: Jean Piché 
> Date: January 25, 2005 7:08:41 PM PST
> To: matt ingalls 
> Subject: serious temp file problem
>
>
> Hi matt,
>
> It looks like the temp0000000 file problem is back with a vengence. 
> The difficulty happens in this circumstance:
> It requires administrator priviledge to write the temp000000 file in 
> the /tmp directory when csound is launched in the background without a 
> terminal.
> A regular user apparently cannot write the file.
> A corrolary problem is that if the file is written by another user 
> with admin provoledges, the file cannot be overwreitten by another 
> with admin priviledges.
> Would it be possible to have csound write the tempfile with full 
> read+write permission for any user?
>
>
> __________________________________________
> Pour en savoir plus / To find out more:
> http://jeanpiche.com
>
>

Does tmpnam() give you paths in /tmp on OS X or does it just return a
filename?  I get a filename with no path on OS 9.

Be aware that if you use tmpfile() then Csound's remove_tmpfiles code will
no longer be needed.  However, I would find this inconvenient since I
sometimes rely on those files not being deleted until I quit Perf so that I
can examine them when hunting for problems.  I was hoping to add a
--keep-temp-files option too to skip the remove_tmpfiles code.  But this
would not be possible with tmpfile().

Also, my docs say that tmpfile() opens a binary file.  I don't know if that
makes any difference.  (Most of the temporary files in Csound are text are
they not)?

Anthony

On 1/25/05 10:33 PM, Matt Ingalls  etched in stone:

> this is the kind of problem that i was predicting a couple weeks back.
> with the  "temp files" post
> 
> i think we should replace all tmpnam() calls with tmpfile() -- at least
> this
> would prevent multiple users and/or multiple processes trying to create
> the
> same file.  if it is true that a 'regular' user cant create files in
> /tmp anyway
> on OSX then i will have to have it write the files somewhere in user's
> space..
> 
> -m



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Jan 26, 2005, at 9:32 AM, Anthony Kozar wrote:

> Does tmpnam() give you paths in /tmp on OS X or does it just return a
> filename?  I get a filename with no path on OS 9.

it just returns the file name.  which ends up putting the temp file in 
the working
directory.  on OSX, the working directory defaults to the directory 
where the
application is, and most users do not have write permission there.  so 
i used
to change the working directory to SFDIR upon launch, but people get 
annoyed
with that, especially if they have something that is crashing, the temp 
files
never get deleted and clutter up the SFDIR.

so i recently added the /tmp manually.  which is nice as it is out of 
sight and even if
csound doesnt delete them [ usually by crashing ] the temp files will 
be deleted next
time the computer is rebooted.

but, the MAIN PROBLEM with using tmpnam is that it always starts with 
the same
filename the first time it is called in a process, so if i am running 2 
csound jobs at
once i am guaranteed to have the 2nd process overwrite the 1st's temp 
files!

one solution i thought of is to create another
file that is not deleted that just stores a number and have csound 
create its own
temp file name, incrementing the stored number each time and then 
appending
that number to the new file name.  this isnt a complete solution though 
as you
still could have a race condition with multiple processes running.  
there also still
might be file permission problems on OSX

>
> Be aware that if you use tmpfile() then Csound's remove_tmpfiles code 
> will
> no longer be needed.  However, I would find this inconvenient since I
> sometimes rely on those files not being deleted until I quit Perf so 
> that I
> can examine them when hunting for problems.  I was hoping to add a

is this as a user or as a programmer?  i dont think most users really 
want
this.  there is of course there is the -t0 option to use score.srt 
instead, although
is this automatically deleted too?

> --keep-temp-files option too to skip the remove_tmpfiles code.  But 
> this
> would not be possible with tmpfile().
>
> Also, my docs say that tmpfile() opens a binary file.  I don't know if 
> that
> makes any difference.  (Most of the temporary files in Csound are text 
> are
> they not)?

oh that might be a problem...

-m

>
> Anthony
>
> On 1/25/05 10:33 PM, Matt Ingalls  etched in 
> stone:
>
>> this is the kind of problem that i was predicting a couple weeks back.
>> with the  "temp files" post
>>
>> i think we should replace all tmpnam() calls with tmpfile() -- at 
>> least
>> this
>> would prevent multiple users and/or multiple processes trying to 
>> create
>> the
>> same file.  if it is true that a 'regular' user cant create files in
>> /tmp anyway
>> on OSX then i will have to have it write the files somewhere in user's
>> space..
>>
>> -m
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Following Micheal Goggin's changes for Csound 5, I added
csoundSetFLTKThreadLocking and csoundGetFLTKThreadLocking calls to the
Csound API.  It seems to be the thing to do until a software bus
approach is fleshed out.  

The csoundSetFLTKThreadLocking function controls whether or not the
FLTK widget thread calls Fl::lock and Fl::unlock, or not (the
default).  Programs with their own FLTK thread should acquire a lock
and enable Csound's FLTK thread locking.  The flCsound programs has
been modified to make use of this new feature.

The change was implemented by adding two files, csound/flktlock.h and
csound/flktlock.hpp to the repository and modifying some files, most
importantly csound/FL_graph.cpp and csound/widgets.cpp.  To ensure
this change breaks no other distribution in the repository, the
benefits of the change are not visible unless one defines
HAVE_FL__LOCK.  

I'm pretty sure a properly thread safe libcsound requires the
insertion of more Fl::lock/Fl::unlock pairs, probably a lot more.  At
least an infrastructure is now present.

There is one more oddity to report.  The FL_run opcode still creates
an non-detached thread.  When locking is enabled, it just creates
windows, and then exists.  Because the thread is not detached,
libcsound does not thinks the performance has been completed when the
windows are created, which is what is wanted.  The problem comes when
figuring out when to exit the process.  Normally, flCsound lets
threads finish up before exiting.  I changed flCsound so that if you
ask it to quit a second time, it immediately calls std::exit.

John


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

To ensure all configurations compile, I found I had to add
csound/flktlock.c in addition to csound/flktlock.h and
csound/flktlock.hpp.  I updated the Linux makefile to add these files
to its build list.

John

ramsdell@mitre.org (John D. Ramsdell) writes:

> Following Micheal Goggin's changes for Csound 5, I added
> csoundSetFLTKThreadLocking and csoundGetFLTKThreadLocking calls to the
> Csound API.  It seems to be the thing to do until a software bus
> approach is fleshed out.  
> 
> The csoundSetFLTKThreadLocking function controls whether or not the
> FLTK widget thread calls Fl::lock and Fl::unlock, or not (the
> default).  Programs with their own FLTK thread should acquire a lock
> and enable Csound's FLTK thread locking.  The flCsound programs has
> been modified to make use of this new feature.
> 
> The change was implemented by adding two files, csound/flktlock.h and
> csound/flktlock.hpp to the repository and modifying some files, most
> importantly csound/FL_graph.cpp and csound/widgets.cpp.  To ensure
> this change breaks no other distribution in the repository, the
> benefits of the change are not visible unless one defines
> HAVE_FL__LOCK.  
> 
> I'm pretty sure a properly thread safe libcsound requires the
> insertion of more Fl::lock/Fl::unlock pairs, probably a lot more.  At
> least an infrastructure is now present.
> 
> There is one more oddity to report.  The FL_run opcode still creates
> an non-detached thread.  When locking is enabled, it just creates
> windows, and then exists.  Because the thread is not detached,
> libcsound does not thinks the performance has been completed when the
> windows are created, which is what is wanted.  The problem comes when
> figuring out when to exit the process.  Normally, flCsound lets
> threads finish up before exiting.  I changed flCsound so that if you
> ask it to quit a second time, it immediately calls std::exit.
> 
> John
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

John,

I can update SConstruct to make it aware of fltklock.c if want me to.
Here is what I think should be changed.

John

diff -u -r1.7 SConstruct
--- SConstruct	20 Jan 2005 07:39:47 -0000	1.7
+++ SConstruct	27 Jan 2005 13:58:22 -0000
@@ -322,6 +322,7 @@
 csound/filopen.c
 csound/filter.c
 csound/flanger.c
+csound/fltklock.c
 csound/fm4op.c
 csound/follow.c
 csound/fout.c
@@ -485,6 +486,7 @@
         csound/getstring.o
         csound/winFLTK.o
         csound/FL_graph.o
+        csound/fltklock.o
         csound/winEPS.o
         csound/winascii.o''')))
 executables.append(csoundProgramEnvironment.Program('dnoise', 
@@ -563,6 +565,7 @@
 	csound/window.o
         csound/winFLTK.o
         csound/FL_graph.o
+        csound/fltklock.o
         csound/winEPS.o
         csound/aifc.o
         csound/winascii.o
@@ -587,6 +590,7 @@
         csound/winEPS.o
         csound/aifc.o
         csound/getstring.o
+        csound/fltklock.o
         csound/FL_graph.o''')))
 executables.append(ustubProgramEnvironment.Program('lpc_export',  
     ['util2/exports/lpc_export.c']))
@@ -637,6 +641,7 @@
 	csound/winEPS.o
         csound/aifc.o
         csound/getstring.o
+        csound/fltklock.o
         csound/FL_graph.o''')))
 executables.append(ustubProgramEnvironment.Program('pvlook',  
     Split('util2/pvlook.dir/pvl_main.c csound/pvlook.o')))



ramsdell@mitre.org (John D. Ramsdell) writes:

> Following Micheal Goggin's changes for Csound 5, I added
> csoundSetFLTKThreadLocking and csoundGetFLTKThreadLocking calls to the
> Csound API.  It seems to be the thing to do until a software bus
> approach is fleshed out.  
> 
> The csoundSetFLTKThreadLocking function controls whether or not the
> FLTK widget thread calls Fl::lock and Fl::unlock, or not (the
> default).  Programs with their own FLTK thread should acquire a lock
> and enable Csound's FLTK thread locking.  The flCsound programs has
> been modified to make use of this new feature.
> 
> The change was implemented by adding two files, csound/flktlock.h and
> csound/flktlock.hpp to the repository and modifying some files, most
> importantly csound/FL_graph.cpp and csound/widgets.cpp.  To ensure
> this change breaks no other distribution in the repository, the
> benefits of the change are not visible unless one defines
> HAVE_FL__LOCK.  
> 
> I'm pretty sure a properly thread safe libcsound requires the
> insertion of more Fl::lock/Fl::unlock pairs, probably a lot more.  At
> least an infrastructure is now present.
> 
> There is one more oddity to report.  The FL_run opcode still creates
> an non-detached thread.  When locking is enabled, it just creates
> windows, and then exists.  Because the thread is not detached,
> libcsound does not thinks the performance has been completed when the
> windows are created, which is what is wanted.  The problem comes when
> figuring out when to exit the process.  Normally, flCsound lets
> threads finish up before exiting.  I changed flCsound so that if you
> ask it to quit a second time, it immediately calls std::exit.
> 
> John
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

ramsdell@mitre.org (John D. Ramsdell) writes:

> I can update SConstruct to make it aware of fltklock.c if want me to.
> Here is what I think should be changed.

I made the changes, as I'm sure you'll need them.

John

> diff -u -r1.7 SConstruct
> --- SConstruct	20 Jan 2005 07:39:47 -0000	1.7
> +++ SConstruct	27 Jan 2005 13:58:22 -0000
> @@ -322,6 +322,7 @@
>  csound/filopen.c
>  csound/filter.c
>  csound/flanger.c
> +csound/fltklock.c
>  csound/fm4op.c
>  csound/follow.c
>  csound/fout.c
> @@ -485,6 +486,7 @@
>          csound/getstring.o
>          csound/winFLTK.o
>          csound/FL_graph.o
> +        csound/fltklock.o
>          csound/winEPS.o
>          csound/winascii.o''')))
>  executables.append(csoundProgramEnvironment.Program('dnoise', 
> @@ -563,6 +565,7 @@
>  	csound/window.o
>          csound/winFLTK.o
>          csound/FL_graph.o
> +        csound/fltklock.o
>          csound/winEPS.o
>          csound/aifc.o
>          csound/winascii.o
> @@ -587,6 +590,7 @@
>          csound/winEPS.o
>          csound/aifc.o
>          csound/getstring.o
> +        csound/fltklock.o
>          csound/FL_graph.o''')))
>  executables.append(ustubProgramEnvironment.Program('lpc_export',  
>      ['util2/exports/lpc_export.c']))
> @@ -637,6 +641,7 @@
>  	csound/winEPS.o
>          csound/aifc.o
>          csound/getstring.o
> +        csound/fltklock.o
>          csound/FL_graph.o''')))
>  executables.append(ustubProgramEnvironment.Program('pvlook',  
>      Split('util2/pvlook.dir/pvl_main.c csound/pvlook.o')))


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net