[Top][All Lists]

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

Re: [MIT-Scheme-devel] working directory

From: Matt Birkholz
Subject: Re: [MIT-Scheme-devel] working directory
Date: Tue, 15 Feb 2011 12:57:39 -0700

> From: Taylor R Campbell <address@hidden>
> Date: Tue, 15 Feb 2011 16:19:08 +0000
> [...]
> I think it would be better to make WITH-WORKING-DIRECTORY-PATHNAME and
> SET-WORKING-DIRECTORY-PATHNAME! match semantics and both interact with
> the operating system.  [...]

Whatever.  I will retract my ummm... pointed questions if you promise
not to dup2() channel 0 from the thread's *current-input-port* at
every thread switch, for the pleasure of /proc/N/fd/0 or egads

> [...]
> I want to spawn threads with wild abandon, too.  That's why I want to
> make sure they don't interfere.  I don't care how fast they run if
> they render Scheme unusably unreliable.

I expect, as an API implementor, to be wrapping callouts with all such
necessary frobination anyway, executed on demand as in ux-make-
subprocess.  If the danged C library must have a particular cwd, I
will add a call to with-process-current-working-directory thusly:

    (with-thread-mutex-locked library-mutex
      (lambda ()
          (lambda ()
              (lambda ()
                (with-process-current-working-directory blah-blah
                  (lambda ()
                    (c-call "danged_library_function" args1 and2 and)))))))))

But please follow your muse; you need promise me nothing.  Scheme is
big enough for create-scsh-thread AND create-light-weight-thread (AND

    (define-integrable create-thread create-light-weight-thread)

too [thanks be to the wisdom of the Ancients]).

(And thanks be too to "../", foul minion of Chaos, for being asleep on
the job, and not bringing its loathsome complexities here. :-)

And no offense to the so-called "Ancients" on the list, for calling
them "ancient".  It's the CPU time?  :-o

reply via email to

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