1Intro(3)              User Contributed Perl Documentation             Intro(3)
2
3
4

Introduction to Coro

6       This tutorial will introduce you to the main features of the Coro
7       module family.
8
9       It first introduces some basic concepts, and later gives a short
10       overview of the module family.
11

What is Coro?

13       Coro started as a simple module that implemented a specific form of
14       first class continuations called Coroutines. These basically allow you
15       to capture the current point execution and jump to another point, while
16       allowing you to return at any time, as kind of non-local jump, not
17       unlike C's "setjmp"/"longjmp". This is nowadays known as a Coro::State.
18
19       One natural application for these is to include a scheduler, resulting
20       in cooperative threads, which is the main use case for Coro today.
21       Still, much of the documentation and custom refers to these threads as
22       "coroutines" or often just "coros".
23
24       A thread is very much like a stripped-down perl interpreter, or a
25       process: Unlike a full interpreter process, a thread doesn't have its
26       own variable or code namespaces - everything is shared. That means that
27       when one thread modifies a variable (or any value, e.g. through a
28       reference), then other threads immediately see this change when they
29       look at the same variable or location.
30
31       Cooperative means that these threads must cooperate with each other,
32       when it comes to CPU usage - only one thread ever has the CPU, and if
33       another thread wants the CPU, the running thread has to give it up. The
34       latter is either explicitly, by calling a function to do so, or
35       implicitly, when waiting on a resource (such as a Semaphore, or the
36       completion of some I/O request). This threading model is popular in
37       scripting languages (such as python or ruby), and this implementation
38       is typically far more efficient than threads implemented in other
39       languages.
40
41       Perl itself uses rather confusing terminilogy - what perl calls a
42       "thread" (or "ithread") is actually called a "process" everywhere else:
43       The so-called "perl threads" are actually artifacts of the unix process
44       emulation code used on Windows, which is consequently why they are
45       actually processes and not threads. The biggest difference is that
46       neither variables (nor code) are shared between processes or ithreads.
47

Cooperative Threads

49       Cooperative threads is what the Coro module gives you. Obviously, you
50       have to "use" it first:
51
52          use Coro;
53
54       To create a thread, you can use the "async" function that automatically
55       gets exported from that module:
56
57          async {
58             print "hello\n";
59          };
60
61       Async expects a code block as first argument (in indirect object
62       notation). You can actually pass it extra arguments, and these will end
63       up in @_ when executing the codeblock, but since it is a closure, you
64       can also just refer to any lexical variables that are currently
65       visible.
66
67       The above lines create a thread, but if you save them in a file and
68       execute it as a perl program, you will not get any output.
69
70       The reasons is that, although you created a thread, and the thread is
71       ready to execute (because "async" puts it into the so-called ready
72       queue), it never gets any CPU time to actually execute, as the main
73       program - which also is a thread almost like any other - never gives up
74       the CPU but instead exits the whole program, by running off the end of
75       the file. Since Coro threads are cooperative, the main thread has to
76       cooperate, and give up the CPU.
77
78       To explicitly give up the CPU, use the "cede" function (which is often
79       called "yield" in other thread implementations):
80
81          use Coro;
82
83          async {
84             print "hello\n";
85          };
86
87          cede;
88
89       Running the above prints "hello" and exits.
90
91       Now, this is not very interesting, so let's try a slightly more
92       interesting program:
93
94          use Coro;
95
96          async {
97             print "async 1\n";
98             cede;
99             print "async 2\n";
100          };
101
102          print "main 1\n";
103          cede;
104          print "main 2\n";
105          cede;
106
107       Running this program prints:
108
109          main 1
110          async 1
111          main 2
112          async 2
113
114       This nicely illustrates the non-local jump ability: the main program
115       prints the first line, and then yields the CPU to whatever other
116       threads there are. And there is one other, which runs and prints "async
117       1", and itself yields the CPU. Since the only other thread available is
118       the main program, it continues running and so on.
119
120       Let's look at the example in more detail: "async" first creates a new
121       thread. All new threads start in a suspended state. To make them run,
122       they need to be put into the ready queue, which is the second thing
123       that "async" does. Each time a thread gives up the CPU, Coro runs a so-
124       called scheduler. The scheduler selects the next thread from the ready
125       queue, removes it from the queue, and runs it.
126
127       "cede" also does two things: first it puts the running thread into the
128       ready queue, and then it jumps into the scheduler. This has the effect
129       of giving up the CPU, but also ensures that, eventually, the thread
130       gets run again.
131
132       In fact, "cede" could be implemented like this:
133
134          sub my_cede {
135             $Coro::current->ready;
136             schedule;
137          }
138
139       This works because $Coro::current always contains the currently running
140       thread, and the scheduler itself can be called directly via
141       "Coro::schedule".
142
143       What is the effect of just calling "schedule" without putting the
144       current thread into the ready queue first? Simple: the scheduler
145       selects the next ready thread and runs it. And the current thread, as
146       it hasn't been put into the ready queue, will go to sleep until
147       something wakes it up. If. Ever.
148
149       The following example remembers the current thread in a variable,
150       creates a thread and then puts the main program to sleep.
151
152       The newly created thread uses rand to wake up the main thread by
153       calling its "ready" method - or not.
154
155          use Coro;
156
157          my $wakeme = $Coro::current;
158
159          async {
160             $wakeme->ready if 0.5 > rand;
161          };
162
163          schedule;
164
165       Now, when you run it, one of two things happen: Either the "async"
166       thread wakes up the main thread again, in which case the program
167       silently exits, or it doesn't, in which case you get something like
168       this:
169
170          FATAL: deadlock detected.
171                PID SC  RSS USES Description              Where
172           31976480 -C  19k    0 [main::]                 [program:9]
173           32223768 UC  12k    1                          [Coro.pm:691]
174           32225088 -- 2068    1 [coro manager]           [Coro.pm:691]
175           32225184 N-  216    0 [unblock_sub scheduler]  -
176
177       Why is that? Well, when the "async" thread runs into the end of its
178       block, it will be terminated (via a call to "Coro::terminate") and the
179       scheduler is called again. Since the "async" thread hasn't woken up the
180       main thread, and there aren't any other threads, there is nothing to
181       wake up, and the program cannot continue. Since there are threads that
182       could be running (main) but none are ready to do so, Coro signals a
183       deadlock - no progress is possible. Usually you also get a listing of
184       all threads, which might help you track down the problem.
185
186       However, there is an important case where progress is, in fact,
187       possible, despite no threads being ready - namely in an event-based
188       program. In such a program, some threads could wait for external
189       events, such as a timeout, or some data to arrive on a socket.
190
191       Since a deadlock in such a case would not be very useful, there is a
192       module named Coro::AnyEvent that integrates threads into an event loop.
193       It configures Coro in a way that, instead of "die"ing with an error
194       message, it instead runs the event loop in the hope of receiving an
195       event that will wake up some thread.
196
197   Semaphores and other locks
198       Using only "ready", "cede" and "schedule" to synchronise threads is
199       difficult, especially if many threads are ready at the same time. Coro
200       supports a number of primitives to help synchronising threads in easier
201       ways. The first such primitives is Coro::Semaphore, which implements
202       counting semaphores (binary semaphores are available as Coro::Signal,
203       and there are Coro::SemaphoreSet and Coro::RWLock primitives as well).
204
205       Counting semaphores, in a sense, store a count of resources. You can
206       remove/allocate/reserve a resource by calling the "->down" method,
207       which decrements the counter, and you can add or free a resource by
208       calling the "->up" method, which increments the counter. If the counter
209       is 0, then "->down" cannot decrement the semaphore - it is locked - and
210       the thread will wait until a count becomes available again.
211
212       Here is an example:
213
214          use Coro;
215
216          my $sem = new Coro::Semaphore 0; # a locked semaphore
217
218          async {
219             print "unlocking semaphore\n";
220             $sem->up;
221          };
222
223          print "trying to lock semaphore\n";
224          $sem->down;
225          print "we got it!\n";
226
227       This program creates a locked semaphore (a semaphore with count 0) and
228       tries to lock it (by trying to decrement it's counter in the "down"
229       method). Since the semaphore count is already exhausted, this will
230       block the main thread until the semaphore becomes available.
231
232       This yields the CPU to the only other read thread in the process,t he
233       one created with "async", which unlocks the semaphore (and instantly
234       terminates itself by returning).
235
236       Since the semaphore is now available, the main program locks it and
237       continues: "we got it!".
238
239       Counting semaphores are most often used to lock resources, or to
240       exclude other threads from accessing or using a resource. For example,
241       consider a very costly function (that temporarily allocates a lot of
242       ram, for example). You wouldn't want to have many threads calling this
243       function at the same time, so you use a semaphore:
244
245          my $lock = new Coro::Semaphore; # unlocked initially - default is 1
246
247          sub costly_function {
248             $lock->down; # acquire semaphore
249
250             # do costly operation that blocks
251
252             $lock->up; # unlock it
253          }
254
255       No matter how many threads call "costly_function", only one will run
256       the body of it, all others will wait in the "down" call. If you want to
257       limit the number of concurrent executions to five, you could create the
258       semaphore with an initial count of 5.
259
260       Why does the comment mention an "operation the blocks"? Again, that's
261       because coro's threads are cooperative: unless "costly_function"
262       willingly gives up the CPU, other threads of control will simply not
263       run. This makes locking superfluous in cases where the function itself
264       never gives up the CPU, but when dealing with the outside world, this
265       is rare.
266
267       Now consider what happens when the code "die"s after executing "down",
268       but before "up". This will leave the semaphore in a locked state, which
269       often isn't what you want - imagine the caller expecting a failure and
270       wrapping the call into an "eval {}".
271
272       So normally you would want to free the lock again if execution somehow
273       leaves the function, whether "normally" or via an exception. Here the
274       "guard" method proves useful:
275
276          my $lock = new Coro::Semaphore; # unlocked initially
277
278          sub costly_function {
279             my $guard = $lock->guard; # acquire guard
280
281             # do costly operation that blocks
282          }
283
284       The "guard" method "down"s the semaphore and returns a so-called guard
285       object. Nothing happens as long as there are references to it (i.e. it
286       is in scope somehow), but when all references are gone, for example,
287       when "costly_function" returns or throws an exception, it will
288       automatically call "up" on the semaphore, no way to forget it. Even
289       when the thread gets "cancel"ed by another thread will the guard object
290       ensure that the lock is freed.
291
292       This concludes this introduction to semaphores and locks. Apart from
293       Coro::Semaphore and Coro::Signal, there is also a reader-writer lock
294       (Coro::RWLock) and a semaphore set (Coro::SemaphoreSet). All of these
295       come with their own manpage.
296
297   Channels
298       Semaphores are fine, but usually you want to communicate by exchanging
299       data as well. Of course, you can just use some locks, and array of
300       sorts and use that to communicate, but there is a useful abstraction
301       for communicaiton between threads: Coro::Channel. Channels are the Coro
302       equivalent of a unix pipe (and very similar to AmigaOS message ports :)
303       - you can put stuff into it on one side, and read data from it on the
304       other.
305
306       Here is a simple example that creates a thread and sends numbers to it.
307       The thread calculates the square of each number and puts that into
308       another channel, which the main thread reads the result from:
309
310          use Coro;
311
312          my $calculate = new Coro::Channel;
313          my $result    = new Coro::Channel;
314
315          async {
316             # endless loop
317             while () {
318                my $num = $calculate->get; # read a number
319                $num **= 2; # square it
320                $result->put ($num); # put the result into the result queue
321             }
322          };
323
324          for (1, 2, 5, 10, 77) {
325             $calculate->put ($_);
326             print "$_ ** 2 = ", $result->get, "\n";
327          }
328
329       Gives:
330
331          1 ** 2 = 1
332          2 ** 2 = 4
333          5 ** 2 = 25
334          10 ** 2 = 100
335          77 ** 2 = 5929
336
337       Both "get" and "put" methods can block the current thread: "get" first
338       checks whether there is some data available, and if not, it block the
339       current thread until some data arrives. "put" can also block, as each
340       Channel has a "maximum item capacity", i.e. you cannot store more than
341       a specific number of items, which can be configured when the Channel
342       gets created.
343
344       In the above example, "put" never blocks, as the default capacity of a
345       Channel is very high. So the for loop first puts data into the channel,
346       then tries to "get" the result. Since the async thread hasn't put
347       anything in there yet (on the first iteration it hasn't even run yet),
348       the result Channel is still empty, so the main thread blocks.
349
350       Since the only other runnable/ready thread at this point is the
351       squaring thread, it will be woken up, will "get" the number, square it
352       and put it into the result channel, waking up the main thread again. It
353       will still continue to run, as waking up other threads just puts them
354       into the ready queue, nothing less, nothing more.
355
356       Only when the async thread tries to "get" the next number from the
357       calculate channel will it block (because nothing is there yet) and the
358       main thread will continue running. And so on.
359
360       This illustrates a general principle used by Coro: a thread will only
361       ever block when it has to. Neither the Coro module itself nor any of
362       its submodules will ever give up the CPU unless they have to, because
363       they wait for some event to happen.
364
365       Be careful, however: when multiple threads put numbers into $calculate
366       and read from $result, they won't know which result is theirs. The
367       solution for this is to either use a semaphore, or send not just the
368       number, but also your own private result channel.
369
370   What is mine, what is ours?
371       What, exactly, constitutes a thread? Obviously it contains the current
372       point of execution. Not so obviously, it also has to include all
373       lexical variables, that means, every thread has its own set of lexical
374       variables.
375
376       To see why this is necessary, consider this program:
377
378          use Coro;
379
380          sub printit {
381             my ($string) = @_;
382
383             cede;
384
385             print $string;
386          }
387
388          async { printit "Hello, " };
389          async { printit "World!\n" };
390
391          cede; cede; # do it
392
393       The above prints "Hello, World!\n". If "printit" wouldn't have its own
394       per-thread $string variable, it would probably print "World!\nWorld\n",
395       which is rather unexpected, and would make it very difficult to make
396       good use of threads.
397
398       To make things run smoothly, there are quite a number of other things
399       that are per-thread:
400
401       $_, @_, $@ and the regex result vars, $&, %+, $1, $2, ...
402           $_ is used much like a local variable, so it gets localised per-
403           thread. The same is true for regex results ($1, $2 and so on).
404
405           @_ contains the arguments, so like lexicals, it also must be per-
406           thread.
407
408           $@ is not obviously required to be per-thread, but it is quite
409           useful.
410
411       $/ and the default output file handle
412           Threads most often block when doing I/O. Since $/ is used when
413           reading lines, it would be very inconvenient if it were a shared
414           variable, so it is per-thread.
415
416           The default output handle (see "select") is a difficult case:
417           sometimes being global is preferable, sometimes per-thread is
418           preferable. Since per-thread seems to be more common, it is per-
419           thread.
420
421       $SIG{__DIE__} and $SIG{__WARN__}
422           If these weren't per-thread, then common constructs such as:
423
424              eval {
425                 local $SIG{__DIE__} = sub { ... };
426                 ...
427              };
428
429           Would not allow coroutine switching. Since exception-handling is
430           per-thread, those variables should be per-thread as well.
431
432       Lots of other esoteric stuff
433           For example, $^H is per-thread. Most of the additional per-thread
434           state is not directly visible to Perl, but required to make the
435           interpreter work. You won't normally notice these.
436
437       Everything else is shared between all threads. For example, the globals
438       $a and $b are shared. When does that matter? When using "sort", these
439       variables become special, and therefore, switching threads when sorting
440       might have surprising results.
441
442       Other examples are the $!, errno, $., the current input line number,
443       $,, "$\", $" and many other special variables.
444
445       While in some cases a good argument could be made for localising them
446       to the thread, they are rarely used, and sometimes hard to localise.
447
448       Future versions of Coro might include more per-thread state when it
449       becomes a problem.
450
451   Debugging
452       Sometimes it can be useful to find out what each thread is doing (or
453       which threads exist in the first place). The Coro::Debug module has
454       (among other goodies), a function that allows you to print a "ps"-like
455       listing - you have seen it in action earlier when Coro detected a
456       deadlock.
457
458       You use it like this:
459
460          use Coro::Debug;
461
462          Coro::Debug::command "ps";
463
464       Remember the example with the two channels and a worker thread that
465       squared numbers? Running "ps" just after "$calculate->get" outputs
466       something similar to this:
467
468               PID SC  RSS USES Description              Where
469           8917312 -C  22k    0 [main::]                 [introscript:20]
470           8964448 N-  152    0 [coro manager]           -
471           8964520 N-  152    0 [unblock_sub scheduler]  -
472           8591752 UC  152    1                          [introscript:12]
473          11546944 N-  152    0 [EV idle process]        -
474
475       Interesting - there is more going on in the background than one would
476       expect. Ignoring the extra threads, the main thread has pid 8917312,
477       and the one started by "async" has pid 8591752.
478
479       The latter is also the only thread that doesn't have a description,
480       simply because we haven't set one. Setting one is easy, just put it
481       into "$Coro::current->{desc}":
482
483          async {
484             $Coro::current->{desc} = "cruncher";
485             ...
486          };
487
488       This can be rather useful when debugging a program, or when using the
489       interactive debug shell of Coro::Debug.
490

The Real World - Event Loops

492       Coro really wants to run in a program using some event loop. In fact,
493       most real-world programs using Coro threads are written with a
494       combination of event-based and thread-based techniques, as it is easy
495       to get the best of both worlds with Coro.
496
497       Coro integrates automatically into any event loop supported by AnyEvent
498       (see Coro::AnyEvent for details), but can take special advantage of the
499       EV and Event modules.
500
501       Here is a simple finger client, using whatever event loop AnyEvent
502       comes up with:
503
504          use Coro;
505          use Coro::Socket;
506
507          sub finger {
508             my ($user, $host) = @_;
509
510             my $fh = new Coro::Socket PeerHost => $host, PeerPort => "finger"
511                or die "$user\@$host: $!";
512
513             print $fh "$user\n";
514
515             print "$user\@$host: $_" while <$fh>;
516             print "$user\@$host: done\n";
517          }
518
519          # now finger a few accounts
520          for (
521             (async { finger "abc", "cornell.edu" }),
522             (async { finger "sebbo", "world.std.com" }),
523             (async { finger "trouble", "noc.dfn.de" }),
524          ) {
525             $_->join; # wait for the result
526          }
527
528       There are a few new things here. First of all, there is Coro::Socket.
529       This module works much the same way as IO::Socket::INET, except that it
530       is coroutine-aware. This means that IO::Socket::INET, when waiting for
531       the network, will block the whole process - that means all threads,
532       which is clearly undesirable.
533
534       On the other hand, Coro::Socket knows how to give up the CPU to other
535       threads when it waits for the network, which makes parallel execution
536       possible.
537
538       The other new thing is the "join" method: All we want to do in this
539       example is start three "async" threads and only exit when they have
540       done their job. This could be done using a counting semaphore, but it
541       is much simpler to synchronously wait for them to "terminate", which is
542       exactly what the "join" method does.
543
544       It doesn't matter that the three "async"s will probably finish in a
545       different order then the for loop "join"s them - when the thread is
546       still running, "join" simply waits. If the thread has already
547       terminated, it will simply fetch its return status.
548
549       If you are experienced in event-based programming, you will see that
550       the above program doesn't quite follow the normal pattern, where you
551       start some work, and then run the event loop (e.v. "EV::loop").
552
553       In fact, nontrivial programs follow this pattern even with Coro, so a
554       Coro program that uses EV usually looks like this:
555
556          use EV;
557          use Coro;
558
559          # start coroutines or event watchers
560
561          EV::loop; # and loop
562
563       And in fact, for debugging, you often do something like this:
564
565          use EV;
566          use Coro::Debug;
567
568          my $shell = new_unix_server Coro::Debug "/tmp/myshell";
569
570          EV::loop; # and loop
571
572       This runs your program, but also an interactive shell on the unix
573       domain socket in /tmp/myshell. You can use the socat program to access
574       it:
575
576          # socat readline /tmp/myshell
577          coro debug session. use help for more info
578
579          > ps
580                  PID SC  RSS USES Description              Where
581            136672312 RC  19k 177k [main::]                 [myprog:28]
582            136710424 -- 1268   48 [coro manager]           [Coro.pm:349]
583          > help
584          ps [w|v]                show the list of all coroutines (wide, verbose)
585          bt <pid>                show a full backtrace of coroutine <pid>
586          eval <pid> <perl>       evaluate <perl> expression in context of <pid>
587          trace <pid>             enable tracing for this coroutine
588          untrace <pid>           disable tracing for this coroutine
589          kill <pid> <reason>     throws the given <reason> string in <pid>
590          cancel <pid>            cancels this coroutine
591          ready <pid>             force <pid> into the ready queue
592          <anything else>         evaluate as perl and print results
593          <anything else> &       same as above, but evaluate asynchronously
594                                  you can use (find_coro <pid>) in perl expressions
595                                  to find the coro with the given pid, e.g.
596                                  (find_coro 9768720)->ready
597          loglevel <int>          enable logging for messages of level <int> and lower
598          exit                    end this session
599
600       Microsft victims can of course use the even less secure
601       "new_tcp_server" constructor.
602
603   The Real World - File I/O
604       Disk I/O, while often much faster than the network, nevertheless can
605       take quite a long time in which the CPU could do other things, if one
606       would only be able to do something.
607
608       Fortunately, the IO::AIO module on CPAN allows you to move these I/O
609       calls into the background, letting you do useful work in the
610       foreground. It is event-/callback-based, but Coro has a nice wrapper
611       around it, called Coro::AIO, which lets you use its functions naturally
612       from within threads:
613
614          use Fcntl;
615          use Coro::AIO;
616
617          my $fh = aio_open "$filename~", O_WRONLY | O_CREAT, 0600
618             or die "$filename~: $!";
619
620          aio_write $fh, 0, (length $data), $data, 0;
621          aio_fsync $fh;
622          aio_close $fh;
623          aio_rename "$filename~", "$filename";
624
625       The above creates a new file, writes data into it, syncs the data to
626       disk and atomically replaces a base file with a new copy.
627
628   Inversion of control - rouse functions
629       Last not least, me talk about inversion of control. The "control"
630       refers to "who calls whom", who is in control of the program. In this
631       program, the main program is in control and passes this to all
632       functions it calls:
633
634          use LWP;
635
636          # pass control to get
637          my $res = get "http://example.org/";
638          # control returned to us
639
640          print $res;
641
642       When switching to event-based programs, instead of "us calling them",
643       "they call us" - this is the inversion of control form the title:
644
645          use AnyEvent::HTTP;
646
647          # do not pass control for long - http_get immediately returns
648          http_get "http://example.org/", sub {
649             print $_[0];
650          };
651
652          # we stay in control and can do other things
653
654       Event based programming can be nice, but sometimes it's just easier to
655       write down some processing in "linear" fashion, without callbacks. Coro
656       provides some special functions to reduce typing:
657
658          use AnyEvent::HTTP;
659
660          # do not pass control for long - http_get immediately returns
661          http_get "http://example.org/", Coro::rouse_cb;
662
663          # we stay in control and can do other things...
664          # ...such as wait for the result
665          my ($res) = Coro::rouse_wait;
666
667       "Coro::rouse_cb" creates and returns a special callback. You can pass
668       this callback to any function that would expect a callback.
669
670       "Coro::rouse_wait" waits (block the current thread) until the most
671       recently created callback has been called, and returns whatever was
672       passed to it.
673
674       These two functions allow you to mechanically invert the control from
675       "callback based style" used by most event-based libraries to "blocking
676       style", whenever you wish to.
677
678       The pattern is simple: instead of...
679
680          some_func ..., sub {
681             my @res = @_;
682             ...
683          };
684
685       ... you write:
686
687          some_func ..., Coro::rouse_cb;
688          my @res = Coro::rouse_wait;
689          ...
690
691       Callback-based interfaces are plenty, and the rouse functions allow you
692       to use them in an often more convenient way.
693

Other Modules

695       This introduction only mentions a few methods and modules, Coro has
696       many other functions (see the Coro manpage) and modules (documented in
697       the "SEE ALSO" section of the Coro manpage).
698
699       Noteworthy modules are Coro::LWP (for parallel LWP requests, but see
700       AnyEvent::HTTP for a better HTTP-only alternative), Coro::BDB, for when
701       you need an asynchronous database, Coro::Handle, when you need to use
702       any file handle in a coroutine (popular to access "STDIN" and "STDOUT")
703       and Coro::EV, the optimised interface to EV (which gets used
704       automatically by Coro::AnyEvent).
705
706       There are a number of Coro-related moduels that might be useful for
707       your problem (see
708       <http://search.cpan.org/search?query=Coro&mode=module>). And since Coro
709       integrates so well into AnyEvent, it's often easy to adapt existing
710       AnyEvent modules (see
711       <http://search.cpan.org/search?query=AnyEvent&mode=module>).
712

AUTHOR

714          Marc Lehmann <schmorp@schmorp.de>
715          http://home.schmorp.de/
716
717
718
719perl v5.36.0                      2023-01-20                          Intro(3)
Impressum