[M3commit] CVS Update: cm3

[Jay]

Hm, maybe it doesn't matter?
I have a bunch of executable source files.
But still, seems wrong.
I could try delete and re-add, but seems not good for so many files, only maybe if it had been the three new ones..
 
jay at ppca:/dev2/cm3/m3-libs/m3core$ ls -lR | grep "x " | grep -v ^dlrwxrwxrwx 1 jay jay      14 2008-12-30 17:33 libm3core.so -> libm3core.so.5-rwxr-xr-x 1 jay jay 1506111 2008-12-30 17:33 libm3core.so.5-rwxr-xr-x  1 jay jay 9206 2008-12-30 16:22 Uwaitpid.quake-rwxr-xr-x 1 jay jay  404 2008-12-28 16:07 Csignal.i3-rwxr-xr-x 1 jay jay 1318 2008-06-03 04:01 Cstdint.i3-rwxr-xr-x 1 jay jay   95 2008-11-11 05:41 Cstdio.i3-rwxr-xr-x 1 jay jay 2158 2008-11-11 05:41 Cstring.i3-rwxr-xr-x 1 jay jay 323 2008-11-12 03:35 Csetjmp.i3-rwxr-xr-x 1 jay jay  23 2008-11-11 06:27 m3makefile-rwxr-xr-x 1 jay jay 14 2008-11-11 05:57 m3makefile-rwxr-xr-x 1 jay jay 207 2008-11-11 20:27 Csetjmp.i3-rwxr-xr-x 1 jay jay  23 2008-11-11 06:27 m3makefile-rwxr-xr-x 1 jay jay 207 2008-11-11 20:27 Csetjmp.i3-rwxr-xr-x 1 jay jay  22 2008-11-11 06:27 m3makefile-rwxr-xr-x 1 jay jay 206 2008-11-11 20:27 Csetjmp.i3-rwxr-xr-x 1 jay jay  23 2008-11-11 06:27 m3makefile-rwxr-xr-x 1 jay jay 207 2008-11-11 20:27 Csetjmp.i3-rwxr-xr-x 1 jay jay  23 2008-11-11 06:27 m3makefile-rwxr-xr-x 1 jay jay 432 2008-05-24 20:08 dtoa.c-rwxr-xr-x 1 jay jay  70 2008-05-24 20:02 m3makefile-rwxr-xr-x 1 jay jay 432 2008-05-24 20:08 dtoa.c-rwxr-xr-x 1 jay jay  70 2008-05-24 20:02 m3makefile-rwxr-xr-x 1 jay jay   18 2008-12-28 03:48 dif1.txt
etc. - Jay



From: jay.krell at cornell.eduTo: m3commit at elegosoft.comSubject: FW: [M3commit] CVS Update: cm3Date: Wed, 31 Dec 2008 20:13:13 +0000

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/5f0ffa41/attachment-0002.html>