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

On 1/26/05 2:24 PM, Matt Ingalls  etched in stone:

> 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.

Sure.  I understand the rationale.  That is nice.

> 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!

As I suggested before, this does not sound like correct behavior for
tmpnam().  It should create a unique name that does not conflict with any
existing files.  Of course, saying "it's a bug" does not solve your problem.
Can you run some simple tests with tmpnam() to make sure that it is at
fault?

> 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

Perhaps a better idea is to retrieve the process id number from the OS and
add that to the temp file name ?

>> 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?

Usually as a developer when trying to find bugs.

Anyways, I hope that we won't have to write a workaround just for OS X on
this issue.

Anthony



-------------------------------------------------------
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 12:27 PM, Anthony Kozar wrote:

> As I suggested before, this does not sound like correct behavior for
> tmpnam().  It should create a unique name that does not conflict with 
> any
> existing files.  Of course, saying "it's a bug" does not solve your 
> problem.
> Can you run some simple tests with tmpnam() to make sure that it is at
> fault?

but it is just a name not a full path, so it cant look anywhere.  thats 
what
tmpfile() is for!

>
> Perhaps a better idea is to retrieve the process id number from the OS 
> and
> add that to the temp file name ?

i did find getuid() - i dont know if
it is on all platforms [ found it in unistd.h ] but using it with

sprintf(sconame, "/tmp/%d/%s", getuid(), tmpnam(NULL));

this seems to work.  i noticed other Mail or someother program is doing 
this too.
but this is only a temporary [ :) ] solution as still
there will be the problem when a single user tries to run 2 instances
at once...



-------------------------------------------------------
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 1/27/05 4:30 PM, Matt Ingalls  etched in stone:

> On Jan 26, 2005, at 12:27 PM, Anthony Kozar wrote:
> 
>> As I suggested before, this does not sound like correct behavior for
>> tmpnam().  It should create a unique name that does not conflict with
>> any

> but it is just a name not a full path, so it cant look anywhere.  thats
> what
> tmpfile() is for!

Hmmmmm ....  you raise an interesting point.

And yet, I just ran a test on OS 9 and confirmed that Perf will _not_
overwrite an existing temp file from a previous run.  It simply chooses the
next available name in sequence.  So, it must be checking the current
directory for available names.

However, looking at the situation on OS X with 4.23f12gbs.7, I find a more
disturbing situation.  It appears here that tmpnam() always returns
/var/tmp/tmp, so that it does not even return unique names for the orc and
sco when using a CSD.  (Of course, csound adds ".orc" and ".sco" so it
works).  But when I run a simple test with two instances of csound
simultaneously here is what I get:

[fiona:~/Projects/csound/orchestras] anthony% cat cs2
#!/bin/tcsh

csound stnoise.csd &
csound ramploops.csd &
[fiona:~/Projects/csound/orchestras] anthony% ./cs2
[1] 761
[2] 762
Using /usr/local/share/csound/csound.xmg
0dBFS level = 32767.0
Csound Version 4.23f12 (12/10/04)
UnifiedCSD:  stnoise.csd
[fiona:~/Projects/csound/orchestras] anthony% Using
/usr/local/share/csound/csound.xmg
0dBFS level = 32767.0
Csound Version 4.23f12 (12/10/04)
UnifiedCSD:  ramploops.csd
STARTING FILE
Creating options
Creating orchestra
STARTING FILE
Creating options
Creating orchestra
Creating /var/tmp/tmp.orc (0xa0006bfc)
Creating /var/tmp/tmp.orc (0xa0006bfc)
Creating score
Creating score
orchname:  /var/tmp/tmp.orc
scorename: /var/tmp/tmp.sco
orchname:  /var/tmp/tmp.orc
orch compiler:
scorename: /var/tmp/tmp.sco
55 lines read
orch compiler:
55 lines read
sorting score ...
[...]
0 errors in performance
peak Ch  1: 32658.775391  (written: 0.996697) at 928440
2584 2048-byte soundblks of shorts written to ramploops.aif (AIFF)
[...]
peak Ch  1: 32658.775391  (written: 0.996697) at 928440
2584 2048-byte soundblks of shorts written to stnoise.aif (AIFF)
WARNING: could not remove /var/tmp/tmp.sco
WARNING: could not remove /var/tmp/tmp.orc

As you can see, both instances use the same temp file names, and both
instances end up reading the orc and sco generated from ramploops.csd and
they create identical outputs.

I am sorry to have argued with you about this Matt.  This is clearly a
problem.

>> Perhaps a better idea is to retrieve the process id number from the OS
>> and
>> add that to the temp file name ?
> 
> i did find getuid() - i dont know if
> it is on all platforms [ found it in unistd.h ] but using it with
> 
> sprintf(sconame, "/tmp/%d/%s", getuid(), tmpnam(NULL));
> 
> this seems to work.  i noticed other Mail or someother program is doing
> this too.
> but this is only a temporary [ :) ] solution as still
> there will be the problem when a single user tries to run 2 instances
> at once...

This is not good enough as my test shows.  That is why I suggested getting
the process ID.  The function getpid() appears to be in the same header as
getuid().

However, I think that perhaps a better solution would be to write our own
thread-safe version of tmpnam() as suggested by Istvan.  Is it possible to
do something like a mutex lock when two different processes are both running
csound with a statically linked csoundlib ??

Anthony



-------------------------------------------------------
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

> However, looking at the situation on OS X with 4.23f12gbs.7, I find a 
> more
> disturbing situation.  It appears here that tmpnam() always returns
> /var/tmp/tmp, so that it does not even return unique names for the orc 
> and

well thats interesting that it writes to /var/tmp -- [  i was just 
using /tmp ]
but also i just made a simple xcode c++ tool that called tmpnam and it 
does
seem to have some kind of random generator on it:

/var/tmp/tmp.0.ydwegM
/var/tmp/tmp.0.d0GRRR
/var/tmp/tmp.0.eDkpsJ

it looks like a BUG in one_file.c blows away any extensions in the temp 
file. i think if this
line is removed the temp files should work:

	if ((p=strchr(orcname, '.')) != NULL) *p='\0'; /* with extention */



in my xcode project i also tried using tmpfile() but i cant find where 
it puts it.
nor can i find a way to get the file name of a FILE pointer, which 
would make
moving to tmpfile() trivial. if there is no way, than it might be a 
messy change.

> This is not good enough as my test shows.  That is why I suggested 
> getting
> the process ID.  The function getpid() appears to be in the same 
> header as
> getuid().
>
> However, I think that perhaps a better solution would be to write our 
> own
> thread-safe version of tmpnam() as suggested by Istvan.  Is it 
> possible to
> do something like a mutex lock when two different processes are both 
> running
> csound with a statically linked csoundlib ??

but does this solve the multiple instances problem?

or we could use tmpfile().
or screw ANSI and just use mktemp() [ with #ifdefs around for non 
compatible compilers ]

at any rate im going to compile my CsoundLib.bundle with xcode and see 
if that
temporarily solves the problem..


-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