EQ2EMu/EQ2/source/depends/boost_1_72_0/libs/process/doc/faq.qbk

[section:faq Frequently Asked Questions]

[section:dead_lock Why does this produce a deadlock?]

Now let's revisit our c++filt example and we will put in an obvious mistake.
This might however be not as obvious for more complex applications.

```
vector<string> demangle(vector<string> in)
{
    
    ipstream is;
    opstream os;
    child c("c++filt", std_out > is, std_in < os);
 
    vector<string> data;   
    for (auto & elem : data)
    {
        string line;
        getline(is, line);
        os << elem;
    }
}
 
```
We switched the read and write operation up, so that's causing a dead-lock.
This locks immediately. This is because `c++filt` expects input, before
outputting any data. The launching process on the other hand waits for its output.

[endsect]

[section:closep Why does the pipe not close?]

Now for another example, which might look correct, let's consider you want
to use `ls` to read the current directory.

```
ipstream is;
child c("ls", std_out > is);

std::string file;
while (is >> file)
    cout << "File: " << file << endl;
   
``` 

This will also deadlock, because the pipe does not close when the subprocess exits.
So the `ipstream` will still look for data even though the process has ended.

[note It is not possible to use automatically pipe-closing in this library, because 
a pipe might be a file-handle (as for async pipes on windows).]

But, since pipes are buffered, you might get incomplete data if you do this:

```
ipstream is;
child c("ls", std_out > is);

std::string file;
while (c.running())
{   
    is >> file;
    cout << "File: " << file << endl;
}
```

It is therefore highly recommended that you use the asynchronous api if you are
not absolutely sure how the output will look.

[endsect]

[section:wchar_t When will the codecvt be used?]

Since windows does not use UTF-8 it is sometimes unavoidable to use the `wchar_t` version of the WinApi.
To keep this library consistent it provides `wchar_t` support on posix also.

Since the posix api is purely `char` every `wchar_t` based type will be converted into `char`.

Windows on the other hand is more selective; the default is to use `char`, 
but if any parameter requires `wchar_t`, everything will be converted to `wchar_t`.
This also includes `boost::filesystem::path`. Additionally, if the system does not provide
the `char` api (as is the case with Windows CE) everything will also be converted.


[endsect]

[endsect]