This is the mail archive of the cygwin@cygwin.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]
Other format: [Raw text]

RE: OT: possible project/research project


> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Stephano Mariani
> Sent: Tuesday, March 19, 2002 7:34 PM
> To: 'Randall R Schulz'; 'Robert Collins'; cygwin@cygwin.com
> Subject: RE: OT: possible project/research project
>
>
> I am no cygwin expert, or windows expert, but isn't the effort better
> spent getting the cygwin fork/vfork to work faster?
>
> Stephano Mariani
>
> PS: Please do not fry me if this is a stupid suggestion or not possible
> because of an obvious flaw, I simply fail to see why the source of the
> problem is not being targeted.
>

I don't see it that the source of the problem is the implementation of
fork/vfork; the way I see it the very *concept* of forking makes little to no
sense.  I've written a lot of code, and not once have I thought to myself, "ok,
now what I want to do here is duplicate the current process in almost exactly
its current state."  Maybe it made more sense back in the day, or maybe I'm
missing something, but it seems to me there's a lot more efficient ways to do
multithreading/multi"process"ing/IPC/etc (or better yet avoid them altogether)
these days.

--
Gary R. Van Sickle
Brewer.  Patriot.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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