This is the mail archive of the cygwin@sourceware.cygnus.com 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]

Re: On the subtleties of using _beginthread to implement fork


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.AAA13154@out1.ibm.net>,  <vischne@ibm.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 <process.h>
> >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@bbc.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@cygnus.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@ecd.rockwell.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@cygnus.com" with one line of text: "help".


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