This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Extend faq.using to discuss fork failures


On Aug 19 09:43, Ryan Johnson wrote:
> Hi all,
> 
> I propose to add an entry to cygwin's faq.using which covers fork
> failures. Frankly, I'm surprised it wasn't there years ago... it's
> certainly frequently-asked, and the answer is always the same. Right
> now users have to trawl the archives to figure out what to do (or
> more likely, just blindly spam the list and get told to rebase
> and/or trawl the list archives).

If you convert the text into a patch against faq-using.xml and send
it to cygwin-patches, I'd take it.

> Also, what is the status of "the spawn family of calls provided by
> Cygwin" [1]? There's nothing about it at the API page [2], and a
> search though the user guide [3] comes up empty as well.

Have a look into the section called "Process Creation".  Granted, it's
not much.  These functions are practically foster children only.

> Searching
> /usr/include turns up only /usr/include/process.h, which contains
> only the function declarations and a single comment -- "This file
> comes with MSDOS and WIN32 systems" -- indicating that Windows, not
> cygwin, provides the functions (which, incidentally, are deprecated

No, no, Cygwin provides these functions as well.  Apart from that, the
process.h file is a problem since it duplicates the exec function
declarations which are given in sys/unistd.h.  I'll remove them.  If you
want to document them as special Cygwin functions, feel free to add a
spawn.sgml file to winsup/cygwin which can be included into the section
about Cygwin-specific functions, like, for instance, path.sgml or
security.sgml.

Your text looks good, except...

> 3. With Vista and later, use peflagsall to set the TS-aware bit on
> all cygwin dlls (see /usr/share/doc/Cygwin/rebase-3.0.1.README,
> reboot needed for changes to take effect). This exploits a side
> effect of address space layout randomization which (ironically)
> causes dlls to nearly always load at the same address.

I'm not sure I ever read about that.  On one hand, the TS-aware flag is
set by gcc 4.x automatically, on the other hand, the TS flag is only
relevant for actual Terminal Servers.
Do you mean the dynamicbase flag, maybe, as described by Chuck at one
point, years ago, on the cygwin-apps list?  Still, I doubt that this
flag has any positive effect, as far as I understand how it works.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]