guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread support plan with initial patch


From: Dirk Herrmann
Subject: Re: Thread support plan with initial patch
Date: Tue, 10 Apr 2001 11:44:03 +0200 (MEST)

On Tue, 10 Apr 2001, NIIBE Yutaka wrote:

> Dirk Herrmann wrote:
>  > Well, I only gave it a short look.  However, at least the patch for
>  > test-suite/lib.scm is out of date and should not be applied.  This will 
>  > most probably also require some of the test cases to be updated.
> 
> OK, I'll examine that part.

It's just that pass-if and friends should not silently convert any return
value into booleans.  I have changed the test-suilte to be more strict
about that:  If pass-if returns anything else than a boolean, this is
considered as an unresolved test case.

>  > It is difficult to figure out at which places you changed my original
>  > patch - at least the auto{conf,make} stuff is from you.  Were there any
>  > additional patches necessary?
> 
> Well, I'll send break-down pieces.  Most parts are just your code
> (following recent update of files).

Great.  I'm looking forward to give it a look.

> My change is a little, basically two:
> 
>       * Add rules for Makefile.am to produce libguileqthreads
>       * Add loading of libguileqthreads on start-up
> 
> Your branch did not build without those changes.  My guess is: you did
> it, but you did forget it to commit, or else?

No, actually I never updated the make files.  I had given instructions on
how to build things manually, because I did not have time to figure out
all that auto{conf,make} stuff at that time.  Thanks for bringing this
into a usable state.

> There's one thing I did not apply from your branch:
> 
>       * __scm.h (SCM_THREAD_DEFER, SCM_THREAD_ALLOW, SCM_THREAD_REDEFER,
>       SCM_THREAD_SWITCHING_CODE, SCM_THREAD_SWITCH_COUNT):  Moved here
>       from threads.h.  These macros, however, may have to be updated in
>       order to be used with other thread packages than coop.
> 
> Because those will be removed by my POSIX thread support.

Good.

It seems that the biggest problem that remains is to figure out about the
problems when linking coop threads with pthreads, right?  As soon as this
has been solved, we should hopefully only have to fix a couple of less
complicated things with my patch, and then integrate it into the main
branch.  (Still assuming that we decide at build time about whether or not
thread support is desired)  Then, the next step would be to provide a
null-thread implementation, which will allow to remove the conditional
compilation of the thread stuff.

Best regards,
Dirk Herrmann




reply via email to

[Prev in Thread] Current Thread [Next in Thread]