How can I read the content of boost::interprocess::file_handle_t?
We are currently prototyping with code found at scoped_lock doesn't work on file?. This demonstrates how to write but we would also like to read from the file. How can this be accomplished? Done the normal google search and looked at boost docs and header files without any luck. Appreciate any input.
#include "boost/format.hpp"
#include "boost/interprocess/detail/os_file_functions.hpp"
namespace ip = boost::interprocess;
namespace ipc = boost::interprocess::detail;
void fileLocking_withHandle()
{
static const string filename = "fileLocking_withHandle.txt";
// Get file handle
boost::interprocess::file_handle_t pFile = ipc::create_or_open_file(filename.c_str(), ip::read_write);
if ((pFile == 0 || pFile == ipc::invalid_file()))
{
throw runtime_error(boost::str(boost::format("File Writer fail to open output file: %1%") % filename).c_str());
}
// Lock file
ipc::acquire_file_lock(pFile);
// Move writing pointer to the end of the file
ipc::set_file_pointer(pFile, 0, ip::file_end);
// Write in file
ipc::write_file(pFile, (const void*)("bla"), 3);
// Unlock file
ipc::release_file_lock(pFile);
// Close file
ipc::close_file(pFile);
}
We are developing on Windows and Linux.
To solve the issue we used platform specific method.
So for Windows platform we used ReadFile(..) [#include "Windows"] and for Linux we used read(..) [#include
Related
I'm writing a tool that makes use of gccxml. Basically I'm parsing the output xml file that has been created by gccxml. This works great on my windows machine in visual studio except for a couple of drawbacks. Here's the current state of my project:
cmake_gui gave me a visual studio solution that compiles perfectly (x64 Release). It's set up to create three executables in E:\cmake_builds\GCCXML\bin\Release.
My own C++ tool is located in a different VS solution file. When it's supposed to make use of gccxml the following code is used:
bool Parser::ParseFile( const std::string& _szFileName, std::string& _gccxmlPath,
const std::string& _tempFileLocation,
std::string& _errorStr)
{
bool retVal = true;
printf("Parsing file %s...\n\n", _szFileName.c_str());
/* format _gccxmlPath, adding a final forward slash to the path if required */
char lastChar = _gccxmlPath.at(_gccxmlPath.length()-1);
if(lastChar != '/' && lastChar != '\\')
_gccxmlPath += "/";
/* set up a temporary environment path variable so that the gccxml exe files may locate each other */
char envPath[500];
sprintf_s(envPath, "PATH=%s", _gccxmlPath.c_str());
const char* gccxml_env[] =
{
/* set path to gccxml directory where all exe files from gccxml are located */
envPath,
0
};
/* path & filename of gccxml.exe */
char gccxml_exe[500];
sprintf_s(gccxml_exe, "%sgccxml.exe", _gccxmlPath.c_str());
/* parameter string used to set gccxml output filename */
char fxmlParam[500];
sprintf_s(fxmlParam, "-fxml=\"%s\"", _tempFileLocation.c_str());
/* synthesize argument list for gccxml*/
/* see: http://gccxml.github.io/HTML/Running.html */
/* and: https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Invoking-GCC.html */
const char* gccxml_args[GCCXML_PARAM_LEN];
unsigned int curPos = 0;
/* 1st argument: exe name */
gccxml_args[curPos++] = "gccxml.exe";
/* the source code to be compiled */
gccxml_args[curPos++] = _szFileName.c_str();
/* try to find out which msvc compiler to use */
gccxml_args[curPos++] = "--gccxml-compiler cl";
/* the output xml file */
gccxml_args[curPos++] = fxmlParam;
/* last argument: zero termination */
gccxml_args[curPos++] = 0;
/* call gccxml & compile the source code file */
if(0 != _spawnvpe(P_WAIT, gccxml_exe, gccxml_args, gccxml_env))
{
_errorStr += "GCCXML Compiler Error";
return false;
}
/* now parse the gccxml output file from tempfile ... */
...
...
return retVal;
}
as you can see I have to set up a local environment PATH variable to make sure the three executables are able to find each other.
This works great for what I want to do.
Unfortunately I can't use this method to call gccxml.exe when I move the three executables to a different directory. Of course I provide the new _gccxmlPath string but gccxml returns
"Support item Vc10/Include is not available..."
telling me that it looked in the folder into which I moved the executables. All my local copies of Vc10/Include however are located somewhere totally different and I don't understand how it had been able find one of these before I moved the executables.
It seems like this problem can be fixed by calling gccxml_vcconfig.exe using the parameters "patch_dir" and providing the directory "gccxml/Source/GCC_XML/VcInstall" from my gccxml source files. I'm, however, not able to solve my issue this way using any of the spawn* commands.
If I do the gccxml_vcconfig.exe runs just fine but after that I'm trying to call gccxml.exe and it turns out that it still looks in the same directory as before.
So gccxml_vcconfig.exe was probably not what I was looking for?
I'm trying to find a way to provide my tool to users who don't want to recompile gccxml on their machine so I'd like to distribute the thre binaries (and what else is needed).
just to let you know. I found a way of doing what I wanted to do. The trick is as follows:
right before vpe-spawning gccxml using its own location as environment (as shown above) vp-spawn the gccxml_vcconfig.exe without providing any environment path variables. This may look like this
std::string VcInstallDir = resolveRelativePath(_gccxmlPath + "../share/gccxml-0.9/VcInstall");
std::string GCCXML09Dir = resolveRelativePath(_gccxmlPath + "../share/gccxml-0.9");
std::vector<const char*> gccxml_config_args;
gccxml_config_args.push_back("gccxml_vcconfig.exe");
gccxml_config_args.push_back(VcInstallDir.c_str());
gccxml_config_args.push_back(GCCXML09Dir.c_str());
gccxml_config_args.push_back(0);
if(0 != _spawnvp(_P_WAIT, gccxml_vcconfig_exe.c_str(), gccxml_config_args.data()))
{
_errorStr += "GCCXML Configuration Error";
return false;
}
note that resolveRelativePath is a self written function for string manipulation that produces a valid absolute path; gccxml_vcconfig_exe contains the absolute path to my exe file
and I somewhat changed my coding style from arrays to std::vectors as you can see
I am installing a new newbuf driver on FreeBSD 10.0 . After compiling with make the driver.ko file has been created and than kldload can load successfully. kldload returns 0 and I can see the device at the kldstat output. When attempt to use the driver opening the /dev/** file, the file is not exist.
I think that this /dev/** file should be created by make_dev function which is located in device_attach member method. To test if the kldload reaches this attaching function; when write printf and uprintf to debug the driver, I can not see any output at console nor dmesg output.
But the problem is after writing printf at beginnings (after local variable definitions) of device_identify and device_probe functions, I can't see any output again at console nor dmesg.
My question is that even if the physical driver has problem (not located etc.), should I see the ouput of printf at the device_identify member function which is called by kldload at starting course (I think)?
Do I have a mistake when debugging newbuf driver with printf (I also tried a hello_world device driver and at this driver I can take output of printf at dmesg)?
Mainly how can I test/debug this driver's kldload processes?
Below some parts of my driver code (I think at least I should see MSG1, but I can not see):
struct mydrv_softc
{
device_t dev;
};
static devclass_t mydrv_devclass;
static struct cdevsw mydrv_cdevsw = {
.d_version = D_VERSION,
.d_name = "mydrv",
.d_flags = D_NEEDGIANT,
.d_open = mydrv_open,
.d_close = mydrv_close,
.d_ioctl = mydrv_ioctl,
.d_write = mydrv_write,
.d_read = mydrv_read
};
static void mydrv_identify (driver_t *driver, device_t parent) {
devclass_t dc;
device_t child;
printf("MSG1: The process inside the identfy function.");
dc = devclass_find("mydrv");
if (devclass_get_device(dc, 0) == NULL) {
child = BUS_ADD_CHILD(parent, 0, "mydrv", -1);
}
}
static int mydrv_probe(device_t dev) {
printf("MSG2: The process inside the probe function.");
mydrv_init();
if (device_get_unit(dev) != 0)
return (ENXIO);
device_set_desc(dev, "FreeBSD Device Driver");
return (0);
}
static int mydrv_attach(device_t dev) {
struct mydrv_softc *sc;
device_printf(dev, "MSG3: The process will make attachment.");
sc = (struct mydrv_softc *) device_get_softc(dev);
sc->dev = (device_t)make_dev(&mydrv_cdevsw, 0, UID_ROOT, GID_WHEEL, 0644, "mydrv_drv");
return 0;
}
static int mydrv_detach(device_t dev) {
struct mydrv_softc *sc;
sc = (struct mydrv_softc *) device_get_softc(dev);
destroy_dev((struct cdev*)(sc->dev));
bus_generic_detach(dev);
return 0;
}
static device_method_t mydrv_methods[] = {
DEVMETHOD(device_identify, mydrv_identify),
DEVMETHOD(device_probe, mydrv_probe),
DEVMETHOD(device_attach, mydrv_attach),
DEVMETHOD(device_detach, mydrv_detach),
{ 0, 0 }
};
static driver_t mydrv_driver = {
"mydrv",
mydrv_methods,
sizeof(struct mydrv_softc),
};
DRIVER_MODULE(mydrv, ppbus, mydrv_driver, mydrv_devclass, 0, 0);
If you don't see your printf's output on your console then your device functions will probably not be called. Can you show us your module's code?
Have you used DRIVER_MODULE() or DEV_MODULE()?
What parent bus are you using?
I guess printf works fine, but I prefer to use device_printf as it also prints the device name, and will be easier when looking through logs or dmesg output. Also leave multiple debug prints and check the log files on your system. Most logs for the device drivers are logged in /var/log/messages. But check other log files too.
Are you running your code on a virtual machine? Some device drivers don't show up their device files in /dev if the OS is running on a virtual machine. You should probably run your OS on actual hardware for the device file to show up.
As far as I know, you can't see the output in dmesg if you cannot find the corresponding device file in /dev but you may have luck with logs as I mentioned.
The easiest way to debug is of course using the printf statements. Other than this, you can debug the kernel using gdb running on another system. I am not familiar with the exact process but I know you can do this. Google it.
I am using an external .txt file to save the incrementing name index for whenever someone "takes a picture" in my app (i.e. image_1.jpg, image_2.jpg, etc...). I am trying to save the data externally so that a user does not overwrite their pictures each time they run the program. However, because of the way that Processing packages its contents for export I cannot both read and write to the same file. It reads the appropriate file located in the apps package contents, however, when it tries to write to that file, it creates a new folder in the same directory as the app itself and writes to a new file with the same name instead.
Essentially, it reads the proper file but refuses to write to it, instead making a copy and writing to that one. The app runs fine but every time you open it and take pictures you overwrite the images you already had.
I have tried naming the "write to" location the explicitly same link as where the exported app stores the data folder inside the package contents (Contents/Resources/Java/data/assets) but this creates a copy of this directory in the same file as the app.
I have also tried excluding the file I am trying to read/write from my data folder when I export the app by changing the read code to ../storage/pictureNumber.txt and then putting this file next to app itself. When I do this the app doesn't launch at all because it is looking in its own data folder for storage and refuses to go outside of itself with ../ . Has anyone had luck both reading from and writing to the same file in an exported processing .app?
Here is the code for the class that is handling the loading and saving of the file:
class Camera {
PImage cameraImage;
int cameraPadding = 10;
int cameraWidth = 60;
int opacity = 0;
int flashDecrementer = 50; //higher number means quicker flash
int pictureName;
Camera() {
String[] pictureIndex = loadStrings("assets/pictureNumber.txt");
pictureName = int(pictureIndex[0]);
cameraImage = loadImage("assets/camera.jpg");
String _pictureName = "" + char(pictureName);
println(pictureName);
}
void display(float mx, float my) {
image(cameraImage, cameraPadding, cameraPadding,
cameraWidth, cameraWidth-cameraWidth/5);
}
boolean isOver(float mx, float my) {
if (mx >= cameraPadding &&
mx <= cameraPadding+cameraWidth &&
my >= cameraPadding &&
my <= cameraPadding+cameraWidth-cameraWidth/5) {
return true;
}
else {
return false;
}
}
void captureImage() {
save("pictures/"+lines.picturePrefix+"_"+pictureName+".jpg");
pictureName++;
String _null = "";
// String _tempPictureName = _null.valueOf(pictureName);
String[] _pictureName = {_null.valueOf(pictureName)};
saveStrings("assets/pictureNumber.txt", _pictureName);
println(_pictureName);
}
void flash() {
fill(255, opacity);
rect(0,0,width,height);
opacity -= flashDecrementer;
if(opacity <= 0) opacity = 0;
}
}
After a lot of searching I found that you have to use savePath() in order to read from a directory outside of the project.jar. The camera class constructor now looks like this:
path = savePath("storage");
println(path);
String[] pictureIndex = loadStrings(path+"/pictureNumber.txt");
pictureName = int(pictureIndex[0]);
cameraImage = loadImage("assets/camera.jpg");
String _pictureName = ""+char(pictureName);
and everything works!
I'm reading some code that uses fopen to open files for writing. The code needs to be able to close and rename these files from time to time (it's a rotating file logger). The author says that for this to happen the child processes must not inherit these FILE handles. (On Windows, that is; on Unix it's OK.) So the author writes a special subroutine that duplicates the handle as non-inheritable and closes the original handle:
if (!(log->file = fopen(log->path, mode)))
return ERROR;
#ifdef _WIN32
sf = _fileno(log->file);
sh = (HANDLE)_get_osfhandle(sf);
if (!DuplicateHandle(GetCurrentProcess(), sh, GetCurrentProcess(),
&th, 0, FALSE, DUPLICATE_SAME_ACCESS)) {
fclose(log->file);
return ERROR;
}
fclose(log->file);
flags = (*mode == 'a') ? _O_APPEND : 0;
tf = _open_osfhandle((intptr_t)th, _O_TEXT | flags);
if (!(log->file = _fdopen(tf, "at"))) {
_close(tf);
return ERROR;
}
#endif
Now, I'm also reading MSDN docs on fopen and see that their version of fopen has a Microsoft-specific flag that seems to do the same: the N flag:
N: Specifies that the file is not inherited by child processes.
Question: do I understand it correctly that I can get rid of that piece above and replace it (on Windows) with an additional N in the mode parameter?
Yes, you can.
fopen("myfile", "rbN") creates a non-inheritable file handle.
The N flag is not mentioned anywhere in Linux documentation for fopen, so the solution will be most probably not portable, but for MS VC it works fine.
I'm porting old linux kernel code for newer version 2.6.32.
There is a part that copies a file descriptor. The idea was to allocate a new file descriptor and a new struct file and use them with another f_op and , leaving all other fields of struct file equivalent to original's.
How do I do this in a modern kernel?
I've written an approximate implementation but I don't know whether i should call file_get, path_get or do others use counter incrementation.
struct file * copy_file(const struct file * iOrig, int * oNewFd) {
if (!orig)
return 0;
*oNewFd = get_unused_fd();
if (*oNewFd < 0)
return 0;
struct file * rv = alloc_file(orig->f_path.mnt, orig->f_path.dentry, orig->f_path.mode, orig->f_op);
if (!rv)
goto free_fd;
fd_install(fd, rv);
return rv;
free_fd:
put_unused_fd(*oNewFd)
return 0;
}
P.S. In fact having all fileds of original file copied is not neccessary. I just need to allow a new set of file operations in user-space. So creating a new descriptor owned by current with a given f_op will do.
path_get sounds fine. Check out an example here http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/fs/pipe.c#L1046 and you'll be able to find more refs there if you need them.