Im basically new in Baqend. Currently, I'm building an application for queueing, but in order to avoid race conditions I need some kind locking mechanism in the system, is Baqend provide that?
Is there any example that i could follow?
Thanks
Baqend has a built in version for each object. If you send an update to an object that has already been changed your update will be denied. In that case you can refresh your local object and try again. Is that what you are looking for?
https://www.baqend.com/guide/topics/crud/#update
Related
I'm trying to create a node interface for a c++ media player. Upon decoding of a frame, there is an event which allows me to access the frame data, which I'm trying to funnel into node. But I can't seem to figure out how to get that kind of functionality to work with the functions available in the node api. My approach, for the time being, is to figure out a push mechanism to get the data from c++ to javascript where all i need is to initialize a callback in javascript, since it seems more elegant. If that fails I could create a polling loop in js to check if there is new frame data, but it seems less efficient.
I've tried with napi_create_async_work, by creating a lambda function in the execute parameter function, which would allow me to call napi_make_callback for every frame callback, but then I get the following error :
Fatal error in HandleScope::HandleScope
Entering the V8 API without proper locking in place
I'm likely approaching this incorrectly, its the first time I use n-api.
Any help is welcome, thank you!
The issue is mainly pertaining to the fact you can’t access V8 (JavaScript) memory outside the event-loop’s main thread. If you're creating an async thread, by default you're also creating a new memory stack.
Fortunately, a fix is on the way which should allow thread safe access with
napi_create_threadsafe_function (example here)
Until then
There is a header only C++ package which integrates great with the C++ N-API wrapper
Napi-addon-api is update. These is a good way that use the Napi::ThreadSafeFunction.
Doc and example.
Could there be any reason why sendARAnimationObject should stop working without any change in the code? Does rendering of bitmaps in a timer depend on any external state like battery level or sensor state etc?
Another issue is that if I use sendARAnimationObjectWithCallback the callback method in the listener onResultSendAnimationObject is never called as stated in the documentation. Could there be any other dependency causing this callback method not called at all?
It works much better with the official SDK v1.0
Now I belive I found the main reason behind. I was not calling disableARAnimationRequest anywhere in my app. Now I am calling it in onPause and it works much better next time I start the app and call enableARAnimationRequest. But I would need someone at sony to confirm this kind of behaviour. Maybe the disable method should be called in some SDK method without putting that burden on the developer. Or some kind of cleanup in SDK when you start your app and enable animation request.
What I want to achieve:
I would like to count the instances of my application to a fixed number.
if more instances of the application are started, it should only work as a "Viewer"
Her is the code of the sample application
boost named_semaphore example
The problem:
it works fine if all processe are started from only one user
But I get a Security exception if I start the application with another user!!
(Access not allowed)
Somebody can point me in the right direction, the boost documentation is a little bit lacking on this topic ;-)
What permissions must be set to allow access from every other logged on user?
I found the solution
Looks like the docu for Boost isn't that bad :-/
http://www.boost.org/doc/libs/1_47_0/doc/html/boost/interprocess/permissions.html
Just have to pass the permission and set it to "unrestricted"
boost::interprocess::permissions permtest;
permtest.set_unrestricted();
_getch();
boost::interprocess::named_semaphore
the_semphore(boost::interprocess::open_or_create,"test_semaphore",3,permtest);
Unfortunately boost uses default security attributes for semaphore and there is no way to change it. Use ATL::CSemaphore or CSemaphore from MFC or even CreateSemaphore from WinApi and construct security descriptor which allows access for everyone.
I'm not exactly a Windows expert, so I can't tell you the answer by heart, but you need to know how named_semaphores are implemented (see "Some basic explanations" documentation of boost.interprocess) and then look up the permission policy for this resource to grant system-wide access. So, read the boost.named_semaphore code, and if they use a file, update that file's permissions, and if they use a system call, read the Windows API documentation for that system call.
Our app is ran from SU or normal user. We have a library we have connected to our project. In that library there is a function we want to call. We have a folder called notRestricted in the directory where we run application from. We have created a new thread. We want to limit access of the thread to file system. What we want to do is simple - call that function but limit its access to write only to that folder (we prefer to let it read from anywhere app can read from).
Update:
So I see that there is no way to disable only one thread from all FS but one folder...
I read your propositions dear SO users and posted some kind of analog to this question here so in there thay gave us a link to sandbox with not a bad api, but I do not really know if it would work on anething but GentOS (but any way such script looks quite intresting in case of using Boost.Process command line to run it and than run desired ex-thread (which migrated to seprate application=)).
There isn't really any way you can prevent a single thread, because its in the same process space as you are, except for hacking methods like function hooking to detect any kind of file system access.
Perhaps you might like to rethink how you're implementing your application - having native untrusted code run as su isn't exactly a good idea. Perhaps use another process and communicate via. RPC, or use a interpreted language that you can check against at run time.
In my opinion, the best strategy would be:
Don't run this code in a different thread, but run it in a different process.
When you create this process (after the fork but before any call to execve), use chroot to change the root of the filesystem.
This will give you some good isolation... However doing so will make your code require root... Don't run the child process as root since root can trivially work around this.
Inject a replacement for open(2) that checks the arguments and returns -EACCES as appropriate.
This doesn't sound like the right thing to do. If you think about it, what you are trying to prevent is a problem well known to the computer games industry. The most common approach to deal with this problem is simply encoding or encrypting the data you don't want others to have access to, in such a way that only you know how to read/understand it.
Alright so to start this is strictly for Windows and I'd prefer to use C++ over .NET but I'm not opposed to boost::filesystem although if it can be avoided in favor of straight Windows API I'd prefer that.
Now the scenario is an application on another machine I can't change is going to create files in a particular directory on the machine that I need to make backups of and do some extra processing. Currently I've made a little application which will sit and listen for change notifications in a target directory using FindFirstChangeNotification and FindNextChangeNotification windows APIs.
The problem is that while I can get notified when new files are created in the directory, modified, size changes, etc it only notifies once and does not specifically tell me which files. I've looked at ReadDirectoryChangesW as well but it's the same story there except that I can get slightly more specific information.
Now I can scan the directory and try to acquire locks or open the files to determine what specifically changed from the last notification and whether they are available for further use but in the case of copying a large file I've found this isn't good enough as the file won't be ready to be manipulated and I won't get any other notifications after the first so there is no way to tell when it's actually done copying unless after the first notification I continually try to acquire locks until it succeeds.
The only other thing I can think of that would be less hackish would be to have some kind of end token file but since I don't have control over the application creating the files in the first place I don't see how I'd go about doing that and it's still not ideal.
Any suggestions?
This is a fairly common problem and one that doesn't have an easy answer. Acquiring locks is one of the best options when you cannot change the thing at the remote end. Another I have seen is to watch the file at intervals until the size doesn't change for an interval or two.
Other strategies include writing a no-byte file as a trigger when the main file is complete and writing to a temp directory then moving the complete file to the real destination. But to be reliable, it must be the sender who controls this. As the receiver, you are constrained to watching the directory and waiting for the file to settle.
It looks like ReadDirectoryChangesW is going to be your best bet. For each file copy operation, you should be receiving FILE_ACTION_ADDED followed by a bunch of FILE_ACTION_MODIFIED notifications. On the last FILE_ACTION_MODIFIED notification, the file should no longer be locked by the copying process. So, if you try to acquire a lock after each FILE_ACTION_MODIFIED of the copy, it should fail until the copy completes. It's not a particularly elegant solution, but there doesn't seem to be any notifications available for when a file copy completes.
You can process the data once the file is closed, right? So the task is to track when the file is closed. This can be done using file system filter driver. You can write your own or you can use our CallbackFilter product.