[M3commit] CVS Update: cm3

[Jay K]

Daniel: I have a low opinion of anything to do with cvs and I believe the way to do anything to improve cvs starts with completing replacing it, therefore it's not worth thinking much about it. In my opinion.


Tony: "You are debasing the primary use-case, which is system threading, to
      support what should be a deprecated target (user threads)."
 
 
I'm "confused". Are user threads meant to work or not? If so, then they
should really definitely work, and not be fragile. I don't think support
should be "too" half hearted. It need not be super efficient, but it should
be super correct. If they don't need to work,
then we should delete/disable/break without pause.
 
 
Currently as far as I understand we are "forced" to use them on OpenBSD.
Probably we should look at what the boehm gc does there though.
Or drop support for OpenBSD until it has kernel threads?
(And not consider supporting DJGPP? :) )
 
 
I don't entirely remember the rationale regarding pthreads on OpenBSD though.
 
Part of the rationale might have been:
  "pthreads have unresolved problems, and are user threads anyway,
  so we might as well just use ours."
 
 
  If that was the final rationale, as I suspect, it might be
  worth more effort getting pthreads to work on OpenBSD, even
  if they are not great and are user threads. At least we'd unify
  our code.
 
 
  You know, we did have problems with pthreads on Darwin, FreeBSD, NetBSD too,
  but we worked through them instead of abandoning pthreads.
  (i.e. "portable suspend/resume, including getting suspended thread context"
  only works on Linux and Solaris, all the rest use custom code.)
 
 
 
 - Jay

________________________________
> Date: Mon, 27 Dec 2010 22:57:54 +0000
> From: dabenavidesd at yahoo.es
> Subject: Re: [M3commit] CVS Update: cm3
> To: hosking at cs.purdue.edu; jkrell at elego.de; jay.krell at cornell.edu
> CC: m3commit at elegosoft.com
>
> Hi all:
> I've read somewhere that cvsup rocks but the disk hit rate is too high,
> wondering it might be that we get to experiment with optical storage
> disk file system like the one in Acorn Archimedes Arx OS, perhaps its
> more appropriate to negotiate the cvsupd requests to the disk without
> hitting it but reading the optical disks data, doing so would be lesser
> time reads than magnetic ones, so that is less usage and the CPU would
> not waste much time going to system threads switching but just user
> space, which might be reasonable for the administrator point of view.
> And FMI besides the source code, is there any documentation available
> for read of dcvs folks?
> Thanks in advance
>
> --- El lun, 27/12/10, Jay K escribió:
>
> De: Jay K
> Asunto: Re: [M3commit] CVS Update: cm3
> Para: "Tony" , "Jay Krell"
> CC: m3commit at elegosoft.com
> Fecha: lunes, 27 de diciembre, 2010 16:34
>
> The code is frequently wrong for user threads.
> So much so that cvsup had cloned some code in order to put in fixes
> along these lines.
> I did undo this though.
>
> - Jay
>
> > From: hosking at cs.purdue.edu
> > Date: Mon, 27 Dec 2010 12:30:38 -0500
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> >
> > You are debasing the primary use-case, which is system threading, to
> support what should be a deprecated target (user threads).
> >
> > Antony Hosking | Associate Professor | Computer Science | Purdue University
> > 305 N. University Street | West Lafayette | IN 47907 | USA
> > Office +1 765 494 6001 | Mobile +1 765 427 5484
> >
> >
> >
> >
> > On Dec 27, 2010, at 1:45 PM, Jay Krell wrote:
> >
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/12/27 13:45:34
> > >
> > > Modified files:
> > > cm3/m3-libs/m3core/src/unix/Common/: UnixC.c
> > >
> > > Log message:
> > > Some wrappers might be used specifically while waiting for
> > > other threads to progress. e.g. don't disable switching in sleep().
> > > More wrappers to consider.
> > > Only matters for user threads..
> >
>
>