Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #7660

Re: bash re-direction?

Show all headers | View raw

On 25/03/13 18:19, Unknown wrote:
> On Sun, 24 Mar 2013 15:47:44 +0000, J G Miller wrote:
>
>> On Sunday, March 24th, 2013, at 10:14:26h +0000, Chris Glur confessed:
>>
>>> When I started learning to read, I learned to spell c.a.t, but I didn't
>>> make a record of the 'authority'.
>>
>> So you admit that your memory is now so bad that you cannot remember who
>> were your primary school teachers?
>
> I can't remember what I had for breakfast; but I fetched, tested and
> filed your pointers to [gnui*? the new one]. The reason why I appear
> stubborn on this [also] matter, is that I didn't WANT to know about ssl,
> but once I've opened the can-o-worms and an important question has been
> raised, I won't just sweep it under the carpet, eg. by buying some snake-
> oil, because the problem [& note, I don't euphemise it to a 'challenge']
> will come back.
> Coming from an embedded background, I lack a valid mental-model of the
> multiple processes talking-to-each-other, and eg. how the shell spawns
> eg. `expect` which sends/receives to/from an tcp-stack ......and........
>
>
well if you are an embedded man, just think of spawning a sub process as 
a rather unwieldy way to call a subroutine, with arguments, and et  a 
return value, or set of values.

If you haven't a basic grasps of multi-tasking, that too is simple in 
principle.

Imagine a hardware interrupt that comes along, saves your stack pointer 
and your register set,  and does its thing and then tidies up and 
replaces the correct values in all the registers  finishing with an 
IRET. The interrupted program carries on.

A multitasking scheduler is just that. And array of tasks that are not 
running exist as - say - register sets copied into specific memory 
places. when a timer interrupt comes along, the interrupt service 
routine looks at all these processes and if it finds a flag has been set 
by some other program that the one suspended, it stores the current 
register set, and the current return value pushed into the stack, and 
loads all the registers from another task, and then pushes THAT tasks 
return value into the stack. Then an Iret will pop the instruction 
pointer back to where THAt task was when the timer interrupted it.


|As long as different tasks don't attempt to share the same memory, they 
can all happily coexist in splendid isolation from each other, and get 
accorded timeslices on the basis of whether they actually have anything 
to do.

that 'whether they have anything to do' is normally assigned by the 
kernel - e.g. when you call for input, you will get suspended until 
input arrives.

You CAN write programs as threads and use one to wake another up, but 
when you want tow actual user space programs to talk, the easiest thing 
to do is to have a daemon. That's a process that is 'attached' to a 
particular input stream, like a tcp/IP or a unix socket, and itself gets 
'woken up' by input to that stream or a request to pull data off it.

Conventionally when it does get woken up, it spawns a copy of itself 
that is attached to that particular conversation, and becomes a separate 
process.

that daemon can then act as a waker-upper of processes that have opened 
a line of communication with it, as well. So if you run ps -eadf or 
similar on  working computer you will see dozens of processes, most of 
them daemons, doing nothing (0%CPU) and waiting for instructions as to 
what to do next.


Those instructions might happen on a timer expiry, or on user input, or 
in asynchronous interrupts from hardware. so if eg an ethernet paclet 
arrives, the kernel ISR accepts it, and passes it to a low level kernel 
daemon who will look at source and destination ports and wake up the 
daemon its assigned to. That daemon will then deal with it and possibly 
respond, then go back to sleep. That daemon might be a web server  and 
dealing with it may involve  spawning an entire copy of the apache 
server, and sending a load of data back. Or it might be something as 
simple as an echo daemon that just says 'I am here' and sends a simple 
packet back.


Mostly you dont need to know this to use it, but sometimes it helps.

-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

bash re-direction? Avoid9Pdf@gmail.com - 2013-03-13 13:37 +0000
  Re: bash re-direction? "Chris F.A. Johnson" <cfajohnson@gmail.com> - 2013-03-13 17:12 -0400
  Re: bash re-direction? Chick Tower <c.tower@deadspam.com> - 2013-03-14 21:24 +0000
    A working incantation for openssl to gmail via SSL and TLS J G Miller <miller@yoyo.ORG> - 2013-03-14 22:01 +0000
      Re: A working incantation for openssl to gmail via SSL and TLS J G Miller <miller@yoyo.ORG> - 2013-03-14 22:18 +0000
    Re: bash re-direction? Unknown <dog@gmail.com> - 2013-03-24 10:14 +0000
      Re: bash re-direction? J G Miller <miller@yoyo.ORG> - 2013-03-24 15:47 +0000
        Re: bash re-direction? Unknown <dog@gmail.com> - 2013-03-25 18:19 +0000
          Re: bash re-direction? J G Miller <miller@yoyo.ORG> - 2013-03-25 20:01 +0000
            Re: bash re-direction? Chick Tower <c.tower@deadspam.com> - 2013-03-27 02:21 +0000
              Re: bash re-direction? J G Miller <miller@yoyo.ORG> - 2013-03-27 13:33 +0000
          Re: bash re-direction? The Natural Philosopher <tnp@invalid.invalid> - 2013-03-26 01:31 +0000
    Re: bash re-direction? Unknown <dog@gmail.com> - 2013-03-24 10:20 +0000

csiph-web