How to dispatch console inputs to different processes

Question

1.00/5 (3 votes)

See more:

Hi,

I am working on multi process environment on embedded Linux Kernel.

How can I make all of my elfs to listen the console without blocking other elfs.

For example:

app1.elf -> call getchar() or similar
app2.elf -> call getchar() or similar
app3.elf -> call getchar() or similar

When I press the say 'a' from the keyboard I want all applications to receive the typed key.

Current behaviour is that if input is captured by app1.elf the others gets nothing.

Any hint will highly be appreciated.

Thanks in advance.

Posted 8-Oct-13 2:14am

_rfk

Updated 8-Oct-13 3:16am

v2

Add a Solution

Comments

pasztorpisti 8-Oct-13 9:40am

The first thing that comes to my mind is that you are trying to solve a problem in the wrong way. If you still insist on solving your problem this way without sharing the actual problem with us then I think sending the input stream with pipes to the other processes is the way to go, but even in this case buffering and blocking pipe write operations can be a problem depending on the actual scenario.

Sergey Alexandrovich Kryukov 8-Oct-13 11:29am

Absolutely, well said. This is like inserting a door key in a wrong lock. This is not a main problem, the bigger problem is that when you try to help, some will say: "just help me to push it harder". :-)
—SA

pasztorpisti 8-Oct-13 11:46am

:-) :-) :-) This is quite typical!

Sergey Alexandrovich Kryukov 8-Oct-13 11:36am

However, OP wanted some hints, so I provided some hint, please see my answer.
As the ultimate goals of this are not explained, this is all... :-)
—SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2013-10-08T05:35:00

Solution 1

Please see the encouraging comments to the question. :-)

It would be hard to help as you apparently are trying to push some misconceptions, but we don't know your ultimate goals which only would make sense to discuss. So, all you can get now is some hints. Here:
http://en.wikipedia.org/wiki/Multithreading_%28software%29#Multithreading[^],
http://www.linuxjournal.com/article/3138[^],
http://en.wikipedia.org/wiki/Inter-process_communication[^],
http://en.wikipedia.org/wiki/Socket_API[^],
http://www.linuxhowtos.org/C_C++/socket.htm[^].

—SA

Posted 8-Oct-13 5:35am

Sergey Alexandrovich Kryukov

Comments

pasztorpisti 8-Oct-13 11:49am

+5. If the solution is linux only then I would advice using multiplexing (select) with nonblocking file handles instead of multithreading. Both are difficult to use but learning/using select tends to be easier for most programmers. Sockets is indeed a good replacement for pipes and its more flexible in exchange for a bit more lines of code.

Sergey Alexandrovich Kryukov 8-Oct-13 12:19pm

Thank you, and — could you explain a bit more on multiplexing select? Could it make an alternative question? (I know, the hassle is not knowing OP's goals...)

As to the sockets: I'm sure you know that sockets, historically, was developed as a pure IPC facility, networks came up later, as the generalization of the socket technology. And, by the way, performance is not compromised if one uses sockets as IPC.

—SA

pasztorpisti 8-Oct-13 12:30pm

I remember that I had to install separate drivers on windows to force loopback connections to go through the network stack in order to be able to capture it. Loopback connections are indeed optimized and work much like pipes. Thinking it over again, multithreading is probably needed (and also buffering) if we want to create a transparent solution that runs in the background while the app uses its original code calling stdio functions (like getchar). Without threading the app code should actively handle the interprocess communication too that would be less clear.

Sergey Alexandrovich Kryukov 8-Oct-13 12:49pm

This is what I though. Generally, I think that the attempts to work around threading by using all kinds of asynchronous APIs is counter-productive. Behind the scene, it is still threading but:
1) threading development is generally linear, with rare synchronizations; it makes the logic simpler;
2) threading approaches is general: you learn them once and use over and over; asynchronous APIs depend on application, you have to learn them separately for each technology.
3) due to more universal character of threading approaches, you can theoretically analyze code using general approaches (such as Petri net); it's good to understand that threading problems are not well fixed by testing and debugging, theoretical correctness is critical.

—SA

pasztorpisti 8-Oct-13 13:11pm

Absolutely true. Multithreading is basically a possible implementation of an async task, and multithreading is always at hand while async APIs are rarely available and even if they are present the interface is always different as you said.
Still, for some reason thread lifetime management and inter-thread communication seems to be something that is impossible to understand for most. Often, the only synchronization point should be only a message queue, sometimes 1-2 shared "databases" and thats it but people like pain in the ass and force themselves to use shared variables... Thread lifetime: maybe the simplest solution that is viable in most cases is precreating threads at startup and deleting them at exit. Instead of this they find very exotic ways to spawn/finish threads.
I've just recalled the last gui+thread related question on CP, the guy kept posting comments/messages to me for weeks relating a very simple background worker thread and he was unable to put together a good solution while step by step instructions were available for him from the very beginnings.

Sergey Alexandrovich Kryukov 8-Oct-13 13:49pm

Right. But, "impossible to understand"? Well, Russians say: "to be afraid of wolves means not going to the forest". :-)
And well, the synchronization properties of queues is just a higher-level technique based on synchronization primitives under the hood (please see http://www.codeproject.com/Tips/149540/Simple-Blocking-Queue-for-Thread-Communication-and showing what's under the hood), and still, these techniques are also very universal and valuable. Do you know another example, Ada Rendezvous?
—SA

pasztorpisti 9-Oct-13 2:19am

I'm not familiar with Ada but reading the wiki paragraph about Rendezvous it seems to be just another (language supported) pattern that is quite easy to implement on top of threads that operate with a blocking message queue. I think thread pools and threads with tasks/jobs are the mother of almost all other patterns. :-)

Sergey Alexandrovich Kryukov 9-Oct-13 2:27am

Not really easy — it does a lot of things and the logic is quite sophisticated yet fully theoretically elaborated. I used the idea in my early implementation of multithreading on a CPU level (did I ever mention that? it was when multithreading wasn't yet introduced in Linux; I implemented some not-fully-featured model of rendezvous and fully-featured structured exception handling, before it was introduced in C++...).
—SA

pasztorpisti 9-Oct-13 2:37am

Yes, you were talking about the multithreading thingy. A bit of nostalgia about good old programming related things reminds me of this blogpost: Programming Isn't Fun Any More.

Sergey Alexandrovich Kryukov 9-Oct-13 10:15am

Ah... "I learn tools". Right. At all times, there were creators and the mere users. Those who "learn tools" are those who turned regular users, solving the problems that in the past were solved by creative people. As I call it, "junk knowledge".

But there is what I think: this is laziness.

"Fun" and creative work always means serious effort. Creative work always existed and will always exist for those who have abilities and, more importantly, the character and strength to get to it. The fields of application change. Maybe, yesterday, calculation of the monetary balance was "fun" and challenge, but now this is just "learning tools". But where do you want to be, with the old field (which is not the same fun anyway), or with "fun"? Some people make decisions and pay for them a lot, some other stay in comfort zone. This is all perfectly normal, but... complaining about it? This is pointless and lazy. We all tend to blame somebody or something else, not ourselves. Instead of blaming that some field of activity which is not such a fun anymore, why the author of this article could not honestly say: "This is me who failed to stay with fun and challenge when times changes; may be I wasn't strong enough for that, or unlucky".

Anyway, it was interesting to see, thank you for sharing. What do you think?

—SA

pasztorpisti 9-Oct-13 12:05pm

To some degree I feel the pain of the author as I've worked for companies that glued together java libs/tools and it was a source of endless boredom for me. On the other hand you can indeed have fun in programming (in worst case at home) but depending on the field of programming you enjoy working on you may extremely limit down your job opportunities and your earning capacity.

Sergey Alexandrovich Kryukov 9-Oct-13 12:29pm

I do feel the pain, too. The authors deserves a credit for pointing out some real pain point here, for spotting a phenomenon. Nevertheless I think my idea of not blaming the changing life but blaming yourself is more constructive, don't you think so? However, it's always more difficult.
As to your last phrase, it comes to this: there is enjoyment and enjoyment. The life is such a thing: if one wants enjoyment and keeping things easy and effortless at the same time, this kind of enjoyment will come to end pretty soon...
—SA

pasztorpisti 9-Oct-13 18:54pm

Many good points and wisdom there. Fortunately my current job allows me to write a lot of fancy stuff because the whole codebase is totally platform independent (win, osx, ios, android, win8, emscripten, ...), full of (memory usage/performance) optimizations and "wheel reinvention" with good reasons. But if I think it over what we do here is just writing the X. iteration of what we have already written many times at home and/or in other projects, just with some customizations and/or improvements over the previous iterations. Quickly collecting the joyful things that helped me to become good programmers the list would be something like:
1. asm coding on my 286/386 and later reverse engineering on win32
2. using/understanding the OS related API and techniques/algorithms I've learnt while I was doing #1
3. reinventing wheels (like network engines, rpc/rmi lib, serialization, ...)
If someone tastes programming today at a typical university he is usually taught:
- that low level coding knowledge is "useless"/not too useful today
- how to use/glue together existing libraries
- NOT TO REINVENT WHEELS, ONLY REUSE CODE (without understanding whats inside, big mistake in my opinion), code ruse, code reuse, code reuse - maybe its just the newcomers who misinterpret this... code reuse is good after all but being too serious about it even at home...

After checking the above lists maybe it isn't mistaken to say that today's new programmers are often not instructed well. A lot of sources instruct them to learn only the boring stuff because only that is useful to serve the needs of an enterprise environment and only a few of them find a better path. Still, even the best enterprise developers usually come with a "wheel reinventing" background being able to see behind the curtains to some degree (for example being able to assume the behavior of the caching of an ORM system or something similar...).

Sergey Alexandrovich Kryukov 9-Oct-13 19:39pm

Of course. What you are describing as the University teaching looks like sabotage, but if you look at what's going on in Russia, including "reorganization" of our Academy of Science...

By the way, it's funny how wrong appeared to be the expression "reinvent the wheel" along with the Russian variant "reinvent the bicycle". Amazingly, these two fields of technology have been a source of especially massive and successful number of inventions, any specialist in cars or bicycles will confirm that. So, having this in mind, the advice to "not reinvent the wheel" could be perceived as the advice "don't make any progress, stay in the cave".

And it has nothing to do with "reuse". Reuse is actually some technology which is permanently reinvented, too.

—SA

pasztorpisti 10-Oct-13 4:49am

The biggest problem is probably the assumed meaning of these advices/words sometimes even by teachers and they give this false knowledge to a new generation.

My opinion:
reusing: sparing time, additionally reusability forces nicer lib interfaces
reinventing the wheel: taking a look behind the curtains, learning whats inside the black box

Even if you write a partial framework that doesn't replace an existing one you gain extremely valuable knowledge. In some cases I discovered that some opensource libs have extremely bad quality after rewriting the same functionality with much less code, less bugs, and nicer interfaces. One of my collegues always says that most opensource C/C++ libs born in the sandbox of some relatively beginner university students who have a lot of free time, thats the reason for the lack of quality most of the time... There may be some truth to this.

Reusing and using third party is sometimes not an option but a mandatory thing as you wouldn't have the time to maintain and develop lot of third party libs especially if their functionality is dynamically changes or follows RFCs... Unfortunately in an enterprise environment most libs fall into this latter category.

Sergey Alexandrovich Kryukov 10-Oct-13 12:33pm

I agree with your views very much, but "reinventing the wheel" could not be possibly understood as just looking inside the black box (under the hood), the important part of it is "invent". Actually, "inventing" could be very positive and very negative, depending on what it is. The biggest fallacy is to discourage of inventions. Again, the remedy against the fallacy is to strongly insist on isolation of the notion of "invention" from "reuse". You can argue that discouraging of invention does not help reuse by, essentially, kills the reuse. Did you meet some lamers who think that reuse if copy-paste? You should not behave like you are looking for excuses for inventions, it would let you down.

The root of the problem is not amount and productivity of the work. The problem is that some people are more or less strong and clever, and others are more or less weak and stupid. It often happens that the weak and stupid hate strong and clever. And such people will do everything to make strong and clever people looking like them or worse. A great teacher will be proud of the student who is much more smart. But the poor teacher will hate a smart student. It happens all the time. Normally, in a healthy environment, those mean people won't dominate. But paradoxically, the technical progress brings more benefits to those stupid and mean people. They won't work hard to learn mathematics, they will find the formula on the Web. And will blame the one who understands that the formula does not work for the case and who can derive all the mathematics as really needed. Blame for "reinventing the wheels". This is where it comes from. We can forget all our rational arguments. Mean people are not rational, they will protect their meanness by all means... :-)
—SA

pasztorpisti 10-Oct-13 13:21pm

Very well said. :-) Unfortunately clever is not always strong enough... Two other variants: weak and clever, strong and stupid (probably most dangerous).

Sergey Alexandrovich Kryukov 10-Oct-13 13:28pm

It depends on what do you call "clever" and "strong", and how you look at it. I mean overall strength, in general: character, adaptability, ability to stand for yourself. Those two variants are minor. Why? "Weak and clever" means "not clever enough". "Strong and stupid"? It means that you are not strong enough, to resist. Yes, we often have problems with such things. But we can only be responsible for ourselves...
—SA