sharing data
BlitzMax Forums/BlitzMax Beginners Area/sharing data
| ||
| Ok. Silly question of the day. (Please be patient...:D) Is there a way to pass data (or sharing resources) between two (or more) programs written in BlitzMax? I know only these 'solutions': 1. passing info via cmd (the master program calls the child via CreateProcess adding arguments...) 2. temp file 3. cmd+temp file 4. IP protocol? Technically I can send an object-address (image or user type, or array) to another process and do something here, right? [this is only an hypotesis...from an address I can't rebuild ALL the info I need - I suppose and I dont' know what can happen accessing the same data by 2 programs...] Any other - and maybe - working solutions you know? |
| ||
| 5. Using shared memory. there is a thread with a windows implementation on the boards. and no you can not share BM objects, they only exist within the own world. you can as well not give out the pointer, that will crash the GC if external code access the object. |
| ||
| 6. Using a shared SQLite database file. This is quite foolproof, easy to implement and fast enough for my purposes. The only drawback is that it creates some disk I/O which could be too much for some really heavy real-time data traffic. |
| ||
| 7. Named Pipes |
| ||
| Ooooh! Thanks, very interesting... |
| ||
| 6. Using a shared SQLite database file. Whilst SQLite database sharing does seem to work for me here in Leopard, "How to corrupt your database files" seems to steer us away from using terms like "foolproof" when speaking about shared database files and SQLite: SQLite uses POSIX advisory locks to implement locking on Unix. On windows it uses the LockFile(), LockFileEx(), and UnlockFile() system calls. SQLite assumes that these system calls all work as advertised. If that is not the case, then database corruption can result. One should note that POSIX advisory locking is known to be buggy or even unimplemented on many NFS implementations (including recent versions of Mac OS X) and that there are reports of locking problems for network filesystems under windows. Your best defense is to not use SQLite for files on a network filesystem. Which is a great pity, I think. But then, I guess mixing "foolproof" and "computers" is probably a bad move generally :-) |
| ||
| Using shared files over SMB network shares is always a bad idea (we've had many cases of data corruption at work), but I haven't had yet any problems sharing a single SQLite database by two Blitz processes when the file is on the local computer. Ok, maybe I still wouldn't call it foolproof, but based on my experience sharing a database with Bruceys wrapper does indeed work on heavy production use. |
| ||
| You could use Brucey's Persistence.mod You can exchange complete objects via file, stream, bank. Pseudo-Code: serializetofile (mylist, "Myfile.txt") And in the receiving application: Local mylist:TList =deseiralizefromfile ("Myfile.txt") and you will have your complete TList back. |
   |