First, does D have the concept of a single-threaded build, or is everything multi-threaded? (Hopefully the latter)

If the process is multithreaded, does a background thread kick the GC every now and then when the other threads are idle? One of the things that I think stinks about .NET is the fact that collection only ever happens in low-memory conditions. Why not have a low-priority background thread, that will rightly be pre-empted by any other threads in the machine, that does it when the machine is in quiescent state?

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btd95p$1o1a$3@digitaldaemon.com...
> First, does D have the concept of a single-threaded build, or is
everything
> multi-threaded? (Hopefully the latter)

Everything is multithreaded.

> If the process is multithreaded, does a background thread kick the GC
every
> now and then when the other threads are idle?

No. A collect is done when an allocation is requested. One could, however, spawn a very low priority thread that will do a collection. What I like to do is in the 'idle' part of the command loop, put the call there.

> One of the things that I think
> stinks about .NET is the fact that collection only ever happens in
> low-memory conditions. Why not have a low-priority background thread, that
> will rightly be pre-empted by any other threads in the machine, that does
it
> when the machine is in quiescent state?

I think DIG has done this, runs colletctions every now and then.  Might give it a gander.

C
"Walter" <walter@digitalmars.com> wrote in message
news:btfl3v$2cs3$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btd95p$1o1a$3@digitaldaemon.com...
> > First, does D have the concept of a single-threaded build, or is
> everything
> > multi-threaded? (Hopefully the latter)
>
> Everything is multithreaded.
>
> > If the process is multithreaded, does a background thread kick the GC
> every
> > now and then when the other threads are idle?
>
> No. A collect is done when an allocation is requested. One could, however, spawn a very low priority thread that will do a collection. What I like to do is in the 'idle' part of the command loop, put the call there.
>
> > One of the things that I think
> > stinks about .NET is the fact that collection only ever happens in
> > low-memory conditions. Why not have a low-priority background thread,
that
> > will rightly be pre-empted by any other threads in the machine, that
does
> it
> > when the machine is in quiescent state?
>
>

How about having a trap in the threads module that creates the low-priority collecting thread only if something calls into the thread library and creates a thread?

That way, people who don't want to have any more than the main thread will not have it forced on them, but those that are creating multiple threads will get this behaviour for free.

"Walter" <walter@digitalmars.com> wrote in message news:btfl3v$2cs3$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btd95p$1o1a$3@digitaldaemon.com...
> > First, does D have the concept of a single-threaded build, or is
> everything
> > multi-threaded? (Hopefully the latter)
>
> Everything is multithreaded.
>
> > If the process is multithreaded, does a background thread kick the GC
> every
> > now and then when the other threads are idle?
>
> No. A collect is done when an allocation is requested. One could, however, spawn a very low priority thread that will do a collection. What I like to do is in the 'idle' part of the command loop, put the call there.
>
> > One of the things that I think
> > stinks about .NET is the fact that collection only ever happens in
> > low-memory conditions. Why not have a low-priority background thread,
that
> > will rightly be pre-empted by any other threads in the machine, that
does
> it
> > when the machine is in quiescent state?
>
>

In article <btfl3v$2cs3$1@digitaldaemon.com>, Walter says...
>
>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btd95p$1o1a$3@digitaldaemon.com...
>> First, does D have the concept of a single-threaded build, or is
>everything
>> multi-threaded? (Hopefully the latter)
>
>Everything is multithreaded.

But aren't there some cases where DMD will not build an object file with thread related code?  Possibly when no language features that require GC are used? Possibly this is really an issue of how the D compiler is implemented? Different D compilers will have a different answer this question?

This has been of particular interest to me since I'm toying around with writing an OS in D without modifying DMD in any way.  A previous effort in this area by Mike Wynn included hacking phobos, but I expect he was trying to retain most of D's features.  His effort was discussed a bit in previous posts. Unfortunately Mike seems to have disappeared, even though his geocities pages are still up, so I've been unable to bounce my idea off of him.

I'm mostly a Java programmer, so OS development is way over my head, but if I'm going to do it, I prefer a stripped down D function set over C.  Maybe I'm crazy :)

I've successfully booted to a rediculously incomplete kernel which does nothing but print to the console (not even keyboard interrupt handling yet).  The kenel code uses modules, but not classes. The kernel was built using DMD as the compiler with the -c option and (ofcourse) gcc with link options that exclude everything but code I've written in D.  I wouldn't think this possible if DMD always created multithreaded object files.

In article <btk998$dau$1@digitaldaemon.com>, Clint Olson says...
>
>In article <btfl3v$2cs3$1@digitaldaemon.com>, Walter says...
>>
>>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btd95p$1o1a$3@digitaldaemon.com...
>>> First, does D have the concept of a single-threaded build, or is
>>everything
>>> multi-threaded? (Hopefully the latter)
>>
>>Everything is multithreaded.
>
>But aren't there some cases where DMD will not build an object file with thread related code?  Possibly when no language features that require GC are used? Possibly this is really an issue of how the D compiler is implemented? Different D compilers will have a different answer this question?
>
>This has been of particular interest to me since I'm toying around with writing an OS in D without modifying DMD in any way.  A previous effort in this area by Mike Wynn included hacking phobos, but I expect he was trying to retain most of D's features.  His effort was discussed a bit in previous posts. Unfortunately Mike seems to have disappeared, even though his geocities pages are still up, so I've been unable to bounce my idea off of him.
>
>I'm mostly a Java programmer, so OS development is way over my head, but if I'm going to do it, I prefer a stripped down D function set over C.  Maybe I'm crazy :)
>
>I've successfully booted to a rediculously incomplete kernel which does nothing but print to the console (not even keyboard interrupt handling yet).  The kenel code uses modules, but not classes. The kernel was built using DMD as the compiler with the -c option and (ofcourse) gcc with link options that exclude everything but code I've written in D.  I wouldn't think this possible if DMD always created multithreaded object files.
>

Whoops, I lied.  I have a tiny amount of non-D code, in assembler, that conforms to the "mutliboot standard" so that grub can interface with it. It simply calls my kernel entry point.

In article <btk998$dau$1@digitaldaemon.com>, Clint Olson says...
>I'm mostly a Java programmer, so OS development is way over my head, but if I'm going to do it, I prefer a stripped down D function set over C.  Maybe I'm crazy :)

You mean WAS over...
maybe the other guys are the crazy ones ;)

>
>I've successfully booted to a rediculously incomplete kernel which does nothing but print to the console (not even keyboard interrupt handling yet)

ah! brave new world!
can you share that?
the more incomplete the better - means less to look at.
just curious.

When I was done with the book "Design your own C compiler in C"
(or some thing like that) I got another called
"Build your own OS" but then I got my first job and...
anyway Mr. Torvalds got there first.

Ant

I would LOVE to see an OS in D.  I think that would 100% ensure its success.

> Mike seems to have disappeared, even though his geocities pages are still
up, so
> I've been unable to bounce my idea off of him.

His last post was not long ago ( a month ? ) so hes still around.

Thats awesome u got it to boot I didn't realize it had gotten even that far. I have NO OS experience but if you get into it i'd defintly try to help ( emphasis on try ;) ).

C

"Clint Olson" <Clint_member@pathlink.com> wrote in message news:btk998$dau$1@digitaldaemon.com...
> In article <btfl3v$2cs3$1@digitaldaemon.com>, Walter says...
> >
> >"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btd95p$1o1a$3@digitaldaemon.com...
> >> First, does D have the concept of a single-threaded build, or is
> >everything
> >> multi-threaded? (Hopefully the latter)
> >
> >Everything is multithreaded.
>
> But aren't there some cases where DMD will not build an object file with
thread
> related code?  Possibly when no language features that require GC are
used?
> Possibly this is really an issue of how the D compiler is implemented? Different D compilers will have a different answer this question?
>
> This has been of particular interest to me since I'm toying around with
writing
> an OS in D without modifying DMD in any way.  A previous effort in this
area by
> Mike Wynn included hacking phobos, but I expect he was trying to retain
most of
> D's features.  His effort was discussed a bit in previous posts.
Unfortunately
> Mike seems to have disappeared, even though his geocities pages are still
up, so
> I've been unable to bounce my idea off of him.
>
> I'm mostly a Java programmer, so OS development is way over my head, but
if I'm
> going to do it, I prefer a stripped down D function set over C.  Maybe I'm
crazy
> :)
>
> I've successfully booted to a rediculously incomplete kernel which does
nothing
> but print to the console (not even keyboard interrupt handling yet).  The
kenel
> code uses modules, but not classes. The kernel was built using DMD as the compiler with the -c option and (ofcourse) gcc with link options that
exclude
> everything but code I've written in D.  I wouldn't think this possible if
DMD
> always created multithreaded object files.
>
>
>
>

> 
> Whoops, I lied.  I have a tiny amount of non-D code, in assembler, that conforms to the "mutliboot standard" so that grub can interface with it. It simply calls my kernel entry point.

Bravo, nonetheless!

I was wondering about the asm part. I assumed at least a little asm code would be necessary.  But I thought all OS's needed that, so the lie is forgivable:). How did you code the assembler portion? Did you put it in a D asm code block?

Nice work!

- John

In article <pan.2004.01.08.22.31.52.199273@telus.net>, John Reimer says...
>
>> 
>> Whoops, I lied.  I have a tiny amount of non-D code, in assembler, that conforms to the "mutliboot standard" so that grub can interface with it. It simply calls my kernel entry point.
>
>Bravo, nonetheless!
>
>I was wondering about the asm part. I assumed at least a little asm code would be necessary.  But I thought all OS's needed that, so the lie is forgivable:). How did you code the assembler portion? Did you put it in a D asm code block?

The asm code I'm using was basically borrowed from the GRUB documentation and is not in a D asm code block.  I haven't used a D asm code block yet becuase I'm not very far along and because its not necessary for manipulating the VGA console, which uses normal memory, rather than I/O memory.

But you are obviously right that an OS endeavor won't get very far without some asm blocks :)