From: banders AT ECD DOT Rockwell DOT COM (Bartlee A. Anderson) Subject: Re: On the subtleties of using _beginthread to implement fork 14 Nov 1997 14:44:01 -0800 Message-ID: <346CD0DA.3574.cygnus.gnu-win32@switch.rockwell.com> References: <199711130033 DOT AAA13154 AT out1 DOT ibm DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gnu-win32 AT cygnus DOT com Chris, As I'm a not quite yet a beginning programmer ;) Could you esplain thum of those missing functions and exaxtly what they would have to do, so that this may be implemented and tested. Rather than left as a trivial exercise for the reader. BTW, do functions that are C, have siblings if they don't inherit from a parent? ;) Bart ;) Chris Faylor wrote: > > Wow. You've convinced me. Anyone who understands GlobalAlloc and > can toss around terms like "disguised sibling" obviously knows what > they're taking about. > > Here's my start at a new fork implementation: > > static _USERENTRY fork2(void *); > int fork() > { > _beginthread(fork2, 4096, NULL); > return 0; > } > static _USERENTRY fork2(void *nada) > { > copy_stack_from_parent(); > set_new_process_id(); > reset_process_start_time(); > copy_heap(); > reset_heap_pointer(); > copy_globals(); > copy_statics(); > set_new_data_segment_ptr(); > copy_fds(); > isolate_scheduling_from_parent(); > isolate_signals_from_parent(); > clear_pending_alarms(); > isolate_interval_timers_from_parent(); > clear_interval_timers(); > set_stack_pointer_from_parent(); // never returns > } > > There are still a few trivial functions left unimplemented, but, as I'm > very busy right now, I'll leave them to the other CYGWIN gurus to write. > > In article <199711130033 DOT AAA13154 AT out1 DOT ibm DOT net>, wrote: > >Some beginning programmer wrote to me that _beginthread was not suitable > >for a fork() implementation because it supposedly uses the `same data > >segment' as its parent process. Without discussing the subtleties of > >calling GlobalAlloc(), or even its disguised sibling, malloc(), I present > >a description of _beginthread(): > > > > > >#include > >unsigned long _beginthread(_USERENTRY (*start_address)(void *), unsigned > >stack_size, void *arglist) > > > >Description > > > >Starts execution of a new thread. > > > >Note: The start_address must be declared to be _USERENTRY. > > > >The _beginthread function creates and starts a new thread. The thread > >starts execution at start_address. > > > >The size of its stack in bytes is stack_size; the stack is allocated by > >the operating system after the stack size is rounded up to the next > >multiple of 4096. The thread is passed arglist as its only parameter; it > >can be NULL, but must be present. The thread terminates by simply > >returning, or by calling _endthread. > > > >Either this function or _beginthreadNT must be used instead of the > >operating system thread-creation API function because _beginthread and > >_beginthreadNT perform initialization required for correct operation of > >the run-time library functions. > > > >This function is available only in the multithread libraries. > > > >Return Value > > > >_beginthread returns the handle of the new thread. > >On error, the function returns -1, and the global variable errno is set to > >one of the following values: > > > >EAGAIN Too many threads > >EINVAL Invalid request > -- > http://www.bbc.com/ cgf AT bbc DOT com "Strange how unreal > VMS=>UNIX Solutions Boston Business Computing the real can be." > - > For help on using this list (especially unsubscribing), send a message to > "gnu-win32-request AT cygnus DOT com" with one line of text: "help". -- Bartlee A. Anderson | Sys. Test (ISDN-Commands-Trans Link-Tools) Rockwell International | Electronic Commerce Division 300 Bauman Ct. | banders AT ecd DOT rockwell DOT com MS 933-605 Opinions my own, not Rockwell's VOICE (630) 227-8975 Wood Dale, IL 60191 | FAX (630) 227-9771 - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".