Redoing conditional thread support

Redoing conditional thread support

[Marius Vollmer]

Hi,

I'm about to reorganize our conditional threading stuff so that there
is always a thread API (scm_current_thread, scm_call_with_new_thread,
mutices, condition variables, etc), but when you configure
"--without-threads" you get a null-thread implementation that doesn't
allow the creation of new threads.  Thus there will always be only a
single thread.

This should make it easier to write code that is thread aware but
doesn't require threads, like the thread-aware sigaction function.

Objections?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Redoing conditional thread support

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

    Marius> This should make it easier to write code that is thread
    Marius> aware but doesn't require threads, like the thread-aware
    Marius> sigaction function.

    Marius> Objections?

Not really, but I'm not sure that this motivation makes sense in
detail, because we could (I think) provide a null implementation like
this in Scheme:

(define-module (ice-9 thread-api-even-if-no-threads))

(or (defined? 'try-mutex)
    (define (try-mutex m) #t))
etc.

But perhaps there are other benefits?

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Redoing conditional thread support

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> >>>>> "Marius" == Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
> 
>     Marius> This should make it easier to write code that is thread
>     Marius> aware but doesn't require threads, like the thread-aware
>     Marius> sigaction function.
> 
>     Marius> Objections?
> 
> Not really, but I'm not sure that this motivation makes sense in
> detail, because we could (I think) provide a null implementation like
> this in Scheme:
> 
> (define-module (ice-9 thread-api-even-if-no-threads))
> 
> (or (defined? 'try-mutex)
>     (define (try-mutex m) #t))
> etc.

That's what I plan to do, in essense.  I want to do it on the C level,
tho, so that C code can just pretend that there is always the concept
of threads and doesn't need to special case when Guile is configured
without real thread support.

The thing is mostly finished, but I got a bit over-ambitious and
implemented almost-real-mutices since Tom made me see that asyncs
could be used to have some kind of cooperating concurrency and so even
without real threads you might want to have mutices and condition
variables, etc.  Something to make a real thread head writhe, I'm
afraid.

> But perhaps there are other benefits?

We can get rid of USE_THREADS and some code will become cleaner and
easier to maintain.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Redoing conditional thread support

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    Marius> That's what I plan to do, in essense.  I want to do it on
    Marius> the C level, tho, so that C code can just pretend that
    Marius> there is always the concept of threads and doesn't need to
    Marius> special case when Guile is configured without real thread
    Marius> support.

Good point.  I forgot that the same argument could apply to C code as
well as Scheme.

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Redoing conditional thread support

[Christopher Cramer]

On Thu, Oct 10, 2002 at 04:51:01PM +0200, Marius Vollmer wrote:
> I'm about to reorganize our conditional threading stuff so that there
> is always a thread API (scm_current_thread, scm_call_with_new_thread,
> mutices, condition variables, etc), but when you configure
> "--without-threads" you get a null-thread implementation that doesn't
> allow the creation of new threads.  Thus there will always be only a
> single thread.

I assume scm_call_with_new_thread without threads would work like
scm_catch? And I guess trying to lock a mutex that's already locked
would give an exception.

-- 
Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/>
"Gore would have finished ahead by the barest of margins had he pursued
and gained a complete statewide recount." -- Associated Press, 9/6/2002


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Redoing conditional thread support

[Marius Vollmer]

Christopher Cramer <crayc@pyro.net> writes:

> On Thu, Oct 10, 2002 at 04:51:01PM +0200, Marius Vollmer wrote:
> > I'm about to reorganize our conditional threading stuff so that there
> > is always a thread API (scm_current_thread, scm_call_with_new_thread,
> > mutices, condition variables, etc), but when you configure
> > "--without-threads" you get a null-thread implementation that doesn't
> > allow the creation of new threads.  Thus there will always be only a
> > single thread.
> 
> I assume scm_call_with_new_thread without threads would work like
> scm_catch?

No, it would throw an error.

> And I guess trying to lock a mutex that's already locked would give
> an exception.

No, it would block until the mutex is unlocked, which might be done by
a async.  I'm not sure whether that's a good idea, tho...


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Redoing conditional thread support

[Mikael Djurfeldt]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> I'm about to reorganize our conditional threading stuff so that there
> is always a thread API (scm_current_thread, scm_call_with_new_thread,
> mutices, condition variables, etc), but when you configure
> "--without-threads" you get a null-thread implementation that doesn't
> allow the creation of new threads.  Thus there will always be only a
> single thread.
> 
> This should make it easier to write code that is thread aware but
> doesn't require threads, like the thread-aware sigaction function.
> 
> Objections?

On the contrary, but Dirk has already made a lot of work on such a
reorganization.  I think there's a branch in the repository which made
a good deal of the way there, if I remember correctly.  Dirk?

The idea was to use a similar technique as has been used in glib,
i.e., a datastructure with a "jump-table" where the initialization
routine of a thread library can "plug in" its C level functions.  The
default values in this datastructure would be the "null" thread
implementation.

The thread interface would be generic enough to allow both for
cooperative threading and pre-emptive threading.  This way, users who
like coop could link guile together with a "libcoop" library and users
who want pthreads could link it with "libguile-pthread" +
"libpthread", while users who don't need threading would not link with
any external thread library.

An important point was that the decision whether to have thread
support or not should *not* be made at compile time since this is a
decision which should be up to the application developer.  This is
possible with the "jump-table" approach described above.

Dirk and I got a long way towards implementing this.  For example, the
data structure mentioned above is implemented.  I'll try to dig up old
documentation + code if you are interested.

Best regards,
Mikael


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Redoing conditional thread support

[Marius Vollmer]

Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

> Dirk and I got a long way towards implementing this.  For example, the
> data structure mentioned above is implemented.  I'll try to dig up old
> documentation + code if you are interested.

Yes, that sounds like a very good thing.  I'll probably just bully
ahead with my null-threads anyway since your approach is so much more
involved that it might be better to get a smaller benefit sooner,
while waiting for the real thing.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel