Mercurial > hg > xemacs-beta
comparison src/callproc.c @ 363:972bbb6d6ca2 r21-1-11
Import from CVS: tag r21-1-11
author | cvs |
---|---|
date | Mon, 13 Aug 2007 10:59:28 +0200 |
parents | 8e84bee8ddd0 |
children | 30d2cfa1092a |
comparison
equal
deleted
inserted
replaced
362:1e474c183006 | 363:972bbb6d6ca2 |
---|---|
609 #ifdef SET_EMACS_PRIORITY | 609 #ifdef SET_EMACS_PRIORITY |
610 if (emacs_priority != 0) | 610 if (emacs_priority != 0) |
611 nice (- emacs_priority); | 611 nice (- emacs_priority); |
612 #endif | 612 #endif |
613 | 613 |
614 /* Under Windows, we are not in a child process at all, so we should | |
615 not close handles inherited from the parent -- we are the parent | |
616 and doing so will screw up all manner of things! Similarly, most | |
617 of the rest of the cleanup done in this function is not done | |
618 under Windows. | |
619 | |
620 #### This entire child_setup() function is an utter and complete | |
621 piece of shit. I would rewrite it, at the very least splitting | |
622 out the Windows and non-Windows stuff into two completely | |
623 different functions; but instead I'm trying to make it go away | |
624 entirely, using the Lisp definition in process.el. What's left | |
625 is to fix up the routines in event-msw.c (and in event-Xt.c and | |
626 event-tty.c) to allow for stream devices to be handled correctly. | |
627 There isn't much to do, in fact, and I'll fix it shortly. That | |
628 way, the Lisp definition can be used non-interactively too. */ | |
614 #if !defined (NO_SUBPROCESSES) && !defined (WINDOWSNT) | 629 #if !defined (NO_SUBPROCESSES) && !defined (WINDOWSNT) |
615 /* Close Emacs's descriptors that this process should not have. */ | 630 /* Close Emacs's descriptors that this process should not have. */ |
616 close_process_descs (); | 631 close_process_descs (); |
617 #endif /* not NO_SUBPROCESSES */ | 632 #endif /* not NO_SUBPROCESSES */ |
633 #ifndef WINDOWSNT | |
618 close_load_descs (); | 634 close_load_descs (); |
635 #endif | |
619 | 636 |
620 /* Note that use of alloca is always safe here. It's obvious for systems | 637 /* Note that use of alloca is always safe here. It's obvious for systems |
621 that do not have true vfork or that have true (stack) alloca. | 638 that do not have true vfork or that have true (stack) alloca. |
622 If using vfork and C_ALLOCA it is safe because that changes | 639 If using vfork and C_ALLOCA it is safe because that changes |
623 the superior's static variables as if the superior had done alloca | 640 the superior's static variables as if the superior had done alloca |