network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 2 years, 1 month |
| seen | Mar 1 at 1:28 | |
| stats | profile views | 3 |
Web developer with a solid software engineering background and design sensibilities. Co-founder of Cantaloop.gr. A bat fastard.
|
Nov 15 |
revised |
Suspended processes in Unix added 178 characters in body |
|
Nov 15 |
awarded | Scholar |
|
Nov 15 |
accepted | Suspended processes in Unix |
|
Nov 15 |
comment |
Suspended processes in Unix That is correct - I was wrong in my assumption that "a suspended process is not 'paused' as it will terminate (or at least 'finish its job') like any other". A suspended process is truly 'paused' while a background process will execute normally. |
|
Nov 15 |
awarded | Student |
|
Nov 15 |
awarded | Supporter |
|
Nov 15 |
revised |
Suspended processes in Unix edited tags |
|
Nov 15 |
awarded | Editor |
|
Nov 15 |
revised |
Suspended processes in Unix added 1 characters in body |
|
Nov 15 |
comment |
Suspended processes in Unix Ok, but why is the suspended state preferable to the background state for this sort of thing? If I had some way of sending the foreground process directly to the background (without first 'suspending') why wouldn't I do that? What is the special value of 'suspended' compared to 'background'? |
|
Nov 15 |
asked | Suspended processes in Unix |
