[M3commit] FW: CVS Update: cm3

[Jay]

It seems some of these files are marked "executable".
How to fix?
I know, locally, chmod -x *, but so that that cvs upd gives you non-executable files?
I'm searching the web but not finding it yet.
 
 - Jay> Date: Wed, 31 Dec 2008 21:05:27 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/12/31 21:05:27> > Modified files:> cm3/m3-libs/m3core/src/thread/: m3makefile > cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 > m3makefile > cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.m3 > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32.m3 m3makefile > cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3 > Added files:> cm3/m3-libs/m3core/src/thread/: ThreadInternal.i3 > ThreadPScheduler.m3 > ThreadPWait.m3 > Removed files:> cm3/m3-libs/m3core/src/thread/WIN32/: WaitProcessCygwin.m3 > WaitProcessWin32.m3 > > Log message:> move code around with the following goals> > fold the three implementations of WaitProcess down to two> minor, would not be done if it was the only point> This is ThreadPWait.m3.> > remove stub SchedulerPosix from NT386 AND NT386GNU> presumably nobody calls the NT386 version, so also (half) minor> > give NT386GNU the real implementation of SchedulerPosix> This is more significant then, e.g. working versions of IOWait (aka select).> This is ThreadPScheduler.m3, moved out of ThreadPThread.m3.> Note that the name is open to debate.> There is this general problem that "P" for posix means two very different things.> It means posix user/alarm threads and posix kernel threads.> (Note that Win32 generalizes select to work on more than just sockets...> either completion ports or WaitForMultipleObjects I assume the generalized analog..)> > provide a /tiny/ abstraction for Posix waitpid users to> provide their own yielding if necessary> This used by WaitProcess.> It potentially for sysutils also, but sysutils can't depend on m3core changes> due to bootstrapping against older m3core.> > The next step is to factor out m3core/threads/m3makefile into> m3core/thread.quake so that sysutils can share its decision as to> if kernel threads are in use and therefore if waitpid yields.> Essentially to copy m3core ThreadPWait plus the other one liner.> If we could rely on newer m3core, then sysutils could just call SchedulerPosix.DoesWaitPidYield().> > This may look scary but it is mainly only moving existing code around,> and very small changes otherwise.> Except for Cygwin which gets the significant improvement of a real SchedulerPosix.> > Since code was moved -- ThreadPThread.m3 split into three files, there> was also a need for an interface so that code moved out of ThreadPThread> could call back to private shared code there, and the other implementation> in ThreadWin32. That is ThreadInternal.i3.> It could be ThreadF.i3, but that would be unnecessarily exposed and worse,> export a variable outside the package, which is a bad idea.> Perhaps wrap up the variable in a function? Maybe.> As well, ThreadF.i3 has three similar copies and this new content would be> needed in two of them. Perhaps the three copies could be combined to one,> with no-op stubs where functions don't make sense (as comments already> indicate exist).> > If cygwin used pthreads, this wouldn't be needed at all.> However, it is reasonable.> Maybe go back and debug Cygwin pthreads again at some point...> Maybe combine ThreadInternal.i3 and ThreadF.i3.> F is "friend" -- aka expose internals to special people, not the> public interface, but sometimes it is needed, thus "F" and "Internal"> are synonyms and you should really never have both, but here they are.> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20081231/144a2c75/attachment-0002.html>