I'm very new to unix programming, so please bear with me. :)
I'd like to pass data between two processes. I was going to use named pipes, but read about these "half-duplex" pipes, and it was very intriguing, so I figured that I would give them a try first.
I have two issues with these pipes thus far:
I haven't figured out how to get execlp to run another application from my child process
Even if I could, debugging is tough because I've only been able to set breakpoints in the parent process
I'm sure there are reasons for these issues. I am starting to wonder if it makes sense to just forget about them and just use named pipes so I can debug each application in a separate instance of eclipse.
If there is any relevant information, please let me know. The code I am using is essentially what it found on tldp.org.
EDIT -- I renamed my question to be about unix pipes in general. I had assumed that for named pipes, I wouldn't have to use fork(), but all of the examples I have seen so far require it. So regardless of half-duplex or named pipes, I'm going to need to be able to debug the child process somehow!
EDIT #2 -- this example clearly shows that what I had seen before (on an IBM link) regarding named pipes wasn't necessarily true.
I recommend two tools:
strace -ff should give you a trace of all significant events, allowing you to examine in detail what's going on, namely, all reads and writes;
lsof allows you to dump file descriptors of involved processes, clearly showing what is connected to what else and, in particular, if you forgot to close() some descriptors and the whole thing deadlocks.
Related
I would like to know Why we need to compile the program of progress 4GL? Really what is happening behind there? Why we are getting .r file after compiled the program? When we check the syntax if its correct then we will get one message box 'Syntax is correct' how its finding the errors and showing the messages.Any explanations welcome and appreciated.
Benefits of compiled r-code include:
Syntax checking
Faster execution (r-code executes faster)
Security (r-code is not "human readable" and tampering with it will likely be noticed)
Licensing (r-code runtime licenses are much less expensive)
For "how its finding the errors and showing the messages" -- at a high level it is like any compiler. It evaluates the provided source against a syntax tree and lets you know when you violate the rules. Compiler design and construction is a fairly advanced topic that probably isn't going to fit into a simple SO question -- but if you had something more specific that could stand on its own as a question someone might be able to help.
The short answer is that when you compile, you're translating your program to a language the machine understands. You're asking two different questions here, so let me give you a simple answer to the first: you don't NEED to compile if you're the only one using the program, for example. But in order to have your program optimized (since it's already at the machine language level) and guarantee no one is messing with your logic, we compile the code and usually don't allow regular users to access the source code.
The second question, how does the syntax checker work, I believe it would be better for you to Google and choose some articles to read about compilers. They're complex, but in a nutshell what they do is take what Progress expects as full, operational commands, and compare to what you do. For example, if you do a
Find first customer where customer.active = yes no-error.
Progress will check if customer is a table, if customer.active is a field in that table, if it's the logical type, since you are filtering if it is yes, and if your whole conditions can be translated to one single true or false Boolean value. It goes on to check if you specified a lock (and default to shared if you haven't, like in my example, which is a no-no, by the way), what happens if there are multiple records (since I said first, then get just the first one) and finally what happens if it fails. If you check the find statement, there are more options to customize it, and the compiler will simply compare your use of the statement to what Progress can have for it. And collect all errors if it can't. That's why sometimes compilers will give you generic messages. Since they don't know what you're trying to do, all they can do is tell you what's basically wrong with what you wrote.
Hope this helps you understand.
According to the documentation for zumero_sync:
If a large amount of information needs to be pulled from the server,
this function may need to be called more than once.
In my Android app that uses Zumero that's no problem; I just keep calling zumero_sync until the return value doesn't start with "0;".
However, now I'm trying to write an admin script that also syncs with my server dbfiles. I'd like to use the sqlite3 shell, and have the script pass the SQL to execute via command line arguments. I need to call zumero_sync in a loop (which SQLite doesn't support) to make sure the db is fully synced. If I had to, I could invoke sqlite3 in a loop (reading its output, looking for "0;"), or even write a C++ app to call the SQLite/Zumero functions natively. But it certainly would be easier if a single zumero_sync was enough.
I guess my real question is: could zumero_sync be changed so it completes the sync before returning? If there are cases where the existing behavior is more useful, maybe there could be a parameter for specifying which mode to use?
I see two basic questions here:
(1) Why does zumero_sync() work the way it does?
(2) Can it work differently?
I'll answer (2) first, since it's easier: Yes, it could work differently. Rather, we could (and probably will, soon, you brought this up) implement an additional function, named something like zumero_sync_complete(), which performs [the guts of] zumero_sync() in a loop and returns after the sync is complete.
We didn't implement zumero_sync_complete() because it doesn't add much value. It's a simple loop, so you can darn well write it yourself. :-)
Er, except in scripting environments which don't support loops. Like the sqlite3 shell.
Answer to (1):
The Zumero sync protocol is designed to give the server the flexibility to return partial results if it wants to do so. And for the sake of reducing load on the server (and increasing its scalability) it often does want to do exactly that.
Given that, one reason to expose this to the client is to increase the client's flexibility as well. As long we're making multiple roundtrips, we might as well give the client an opportunity to do something (like, maybe, update a progress bar) in between them.
Another thing a client might want to do in between loop iterations is handle an error.
Or, in the case of a multithreaded client, it might want to deal with changes that happened on the client while the sync is going on.
Which raises the question of how locking should be managed? Do we hold the sqlite write lock during the entire loop? Or only when absolutely necessary?
Bottom line: A robust app would probably want to implement the loop itself so that it can make its own decisions and retain full control over things.
But, as you observe, the sqlite3 shell doesn't have loops. And it's not an app. And it doesn't have threads. Or progress bars. So it's a use case where a simpler-and-less-powerful form of zumero_sync() would make sense.
Newbie Common Lisp question here.
Is there a way to reset the state of the environment? What I mean, is there some command that brings the REPL back to the same state it was right after it started up, that is, uninterning all variables, functions, etc. Or if that's not in the Common Lisp standard, is there some extension in SBCL (the implementation I use) to do that?
(EDIT: I know that in SLIME, M-x slime-restart-inferior-lisp does that but I wonder if there's a way without restarting the process)
Not in general, no. I occasionally want to do something like that, so my workflow is generally to create a new package to hold whatever project I'm starting, then when I want to reset things I use DELETE-PACKAGE. I never do any work in the CL-USER package, since different implementations have different things stuffed into it.
Use C-c M-o, as given in REPL menu's Clear Buffer
another quick question, I want to make simple console based game, nothing too fancy, just to have some weekend project to get more familiar with C. Basically I want to make tetris, but I end up with one problem:
How to let the game engine go, and in the same time wait for input? Obviously cin or scanf is useless for me.
You're looking for a library such as ncurses.
Many Rogue-like games are written using ncurses or similar.
There's two ways to do it:
The first is to run two threads; one waits for input and updates state accordingly while the other runs the game.
The other (more common in game development) way is to write the game as one big loop that executes many times a second, updating game state, redrawing the screen, and checking for input.
But instead of blocking when you get key input, you check for the presence of pending keypresses, and if nothing has happened, you just continue through your loop. If you have multiple input sources (keyboard, network, etc.) they all get put there in the loop, checking one after another.
Yes, it's called polling. No, it's not efficient. But high-end games are usually all about pulling the maximum performance and framerates out of the computer, not running cool.
For added efficiency, you can optionally block with a timeout -- saying "wait for a keypress, but no longer than 300 milliseconds" so you can continue on with your loop.
select() comes to mind, but there are other ways of waiting or checking for input as well.
You could work out how to change stdin to non-blocking, which would enable you to write something like tetris, but the game might be more directly expressed in an event-driven paradigm. Maybe it's a good excuse to learn windows programming.
Anyway, if you want to go the console route, if you are using the microsoft compiler, then you should have kbhit() available (via conio.h) which can tell you whether a call to fgetc on stdin would block.
Actually should mention that the MinGW gcc compiler 3.4.5 also supports kbhit().
Let's say you have a function foo() compiled into a program that is running on Unix.
While the program is running, can one "replace" the function foo by dynamically loading an object file containining a modified version of foo()?
On an embedded system I worked on in the past, we could unprotect the text segment and then essentially "patch" the address of foo() to point to the newly modified foo().
It was used for debugging on occasion and with lots of special constraints, on customer sites.
Is this possible on Unix?
It depends on the environment, I suppose. I know that hot-swapping production code is trivial in Erlang modules and not too difficult in Ruby. C might be a different animal.
Yes. That's how debuggers like gdb work, after all.
The short of it is yes, of course it's possible. The question should really be, "how difficult?"
You can load & unload shared libraries (.so & .DLL) all you want on Linux & Windows. Specific variants of UNIX, I'm not sure about. This would be the easiest way to achieve your goal.
If you don't mind getting your hands dirty, you can always patch up the code segment to jump to someplace else out on the heap. I don't recommend it.