Problems understanding io.write in embedded application

["Keith Pimmel" <pimmel@...>]

I'm really confused.

I have embedded Lua inside of a MATLAB/Simulink model that uses their
RealTime Workshop (RTW) features that converts native Simulink/MATLAB
code into compiled C code.

Some (coarse) background on the composition of the model: Simulink
allows user-defined extensions using custom C blocks that are imported
as DLLs. I have made my own block that is reliant upon the Lua DLL.

I use my Lua state as a data marshalling service, that aggregates the
output data and then delivers the data in a variety of formats
including plain ASCII text, native MATLAB Type-4 file format, and in
the future, we might need to push data on the wire through sockets,
etc...

My platform is Windows XP SP2. The RTW code is currently using the lcc
compiler that is shipped with MATLAB/Simulink. My Lua libraries are
compiled with MinGW. I'm using lhf's pack library as well as Kepler's
lfs.

When I read input files, I encounter no issues whatsoever. Whenever I
try to write to a file, though, my program hangs and I get the
friendly pop-up window "Windows has encountered a problem. Would you
like to report it?".
When I execute the code in a stand-alone lua interpreter, there is no
problem with my code, which makes me think that my output file handles
are getting nerfed somehow, but I don't know how to diagnose it.

Some code snippets that illustrate my problem:

out[i]=assert(io.open('scenario/'..scenario .. '/' .. scenario ..
output_file_count .. '.mat','w+b')) -- works in both stand-alone lua
and embedded
print(io.type(out[i])) -- prints 'file' for both cases
tmp = spack('i',0)  -- spack is aliased to string.pack; this works for
both cases
out[i]:write(tmp)  -- works in interpreter, hangs when executed in
embedded code.

I hope I'm missing something obvious here, but I couldn't find
anything in the list archives on output file handles not working, nor
did I find anything in PiL or the reference manual. If anyone has any
insight as to what is going on and what I might need to do to fix it,
I would be very grateful. As it is, I'm thinking of having to dump all
the data back to my C code in Simulink, which doubles my data transfer
(which is a going to be a lot), and really eliminates the point of
having an embedded engine for data processing in the first place.


Kind regards,
Keith
--
Keith Pimmel