"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btg1b6$pc$1@digitaldaemon.com...
> 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.

The library is multithreaded regardless of whether the programmer creates multiple threads or not. In any case, a low priority thread doing gc doesn't really add much.

"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?

Not really sure what you mean. What's wrong with multithread capability anyway?

>  Possibly when no language features that require GC are used?

?? GC is not really wrapped up in the multithreading issue.

> Possibly this is really an issue of how the D compiler is implemented?

No. How the compiler itself is implemented and how the runtime library works are independent.

> Different D compilers will have a different answer this question?

I don't really see how.

> 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
> :)

Sure you can strip down the library. But that would not affect the compiler.

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

There is some misunderstanding here about what a multithread object file is.

"Walter" <walter@digitalmars.com> wrote in message news:bu850e$2gd9$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btg1b6$pc$1@digitaldaemon.com...
> > 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.
>
> The library is multithreaded regardless of whether the programmer creates multiple threads or not. In any case, a low priority thread doing gc
doesn't
> really add much.

Doesn't it execute finalisers? That could release other kinds of resources, and free up resources

In article <bu850f$2gd9$2@digitaldaemon.com>, Walter says...
>
>
>"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?
>
>Not really sure what you mean. What's wrong with multithread capability anyway?

There's nothing wrong with it, I was just trying to figure out if I could build an executable that didn't rely on calls to the underlying OS, which I assume threads, and therefore GC, require.

Unless my experiments in OS development in D are not comprehensive enough (quite possible) it seems that one can create executables in D that are not multithreaded.  Otherwise, I would not be able to link my DMD created object files without the pthreads library (what Phobos uses in Linux?).

Maybe I should think of it this way.  D is the combination of a compiler and a library.  While the library may be multithreaded, the compiler doesn't care one way or the other if you use the library.  The best way for me to avoid getting caught using features of the D language that require calls to an underlying OS is to eliminate phobos from the development process altogether.

This obviously means that several language features, like classes, are out, since object.d is part of phobos.  Now I'm starting to see why Mike Wynn was hacking phobos to create his d-kernel.

>
>>  Possibly when no language features that require GC are used?
>
>?? GC is not really wrapped up in the multithreading issue.

Except that GC runs in a separate thread. right?

>
>> Possibly this is really an issue of how the D compiler is implemented?
>
>No. How the compiler itself is implemented and how the runtime library works are independent.

Hey, that's what I said above.  Sorry, I'm really showing my ignorance by not catching on to this sooner.  Maybe too much Java, where the runtime and library are unavoidable, has adversly affected my brain...

>
>> Different D compilers will have a different answer this question?
>
>I don't really see how.
>
>> 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
>> :)
>
>Sure you can strip down the library. But that would not affect the compiler.
>

Got it.

>> 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.
>
>There is some misunderstanding here about what a multithread object file is.
>

Quite possibly.  I guess I meant object files with calls to a thread library. Bottom line, it is possible create object files with DMD which do not make calls to the underlying OS for threading, GC, or anything else.  While many portions of phobos do not require calls to the underlying OS, a brute force method to preclude calls to the underlying OS would be to eliminate phobos from the compile and link steps.  (and ofcourse, not to include any other libraries that also required calls to the underlying OS).

Sound about right?

"Clint Olson" <Clint_member@pathlink.com> wrote in message news:bvucj5$ukt$1@digitaldaemon.com...
> Except that GC runs in a separate thread. right?

No, it does not.

Walter wrote:

> "Clint Olson" <Clint_member@pathlink.com> wrote in message
> news:bvucj5$ukt$1@digitaldaemon.com...
> 
>>Except that GC runs in a separate thread. right?
> 
> 
> No, it does not.

When does it run, then?

A possibility would be to run it when someone wants to allocate heap memory and there isn't enough available. GC would then run in the context of the thread that calls new.

That would mean that the destructor of an object would run in an unknown thread. Or in other words, you can't control which thread calls an object's destructor.

Is that any better than having the GC run in its own thread?

Or does it work differently?

Cheers
Stefan

Stefan Heinzmann wrote:

> Walter wrote:
>
>> "Clint Olson" <Clint_member@pathlink.com> wrote in message
>> news:bvucj5$ukt$1@digitaldaemon.com...
>>
>>> Except that GC runs in a separate thread. right?
>>
>>
>>
>> No, it does not.
>
>
> When does it run, then?
>
> A possibility would be to run it when someone wants to allocate heap memory and there isn't enough available. GC would then run in the context of the thread that calls new.
>
> That would mean that the destructor of an object would run in an unknown thread. Or in other words, you can't control which thread calls an object's destructor.
>
> Is that any better than having the GC run in its own thread?
>
> Or does it work differently?
>
> Cheers
> Stefan
>
My understanding is that when the GC runs it pauses all threads.   The GC runs when the systems starts getting low on memory (ie when the program tries to allocate some more and some threshold is met.)  Of course this is only for the dmd version of the GC.  Other vendors may choose to use different GC's.

-- 
-Anderson: http://badmama.com.au/~anderson/