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: Stephano Mariani [mailto:sk.mail@btinternet.com] 
> Sent: Wednesday, March 20, 2002 12: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.

Fry Fry!

Seriously though, reducing the overhead of fork() is a great idea. (BTW:
vfork is a different beast, it's ~ spawn() and that's OK.).
Unfortunately that requires kernel-level coding for NT, and/or kernel
level object modification to win9x on-the-fly. IOW it's going to be
unreliable for one and horribly complexify cygwin's innards for the
other (NT).

In fact cgf has had a copy-on-write fork() for cygwin in alpha-quality
IIRC. I'd love to do some perf tests with that, and in fact on my todo
list is cygwin profiling. Time however, is the killer.

Rob

--
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]