Greetings!
Just a heads up that I've committed some preliminary work in this
regard. I have a dual machine (each real cpu two-way 'hyperthreaded'),
and here is an example of the behavior I see. YMMV, of course:
=
input
=
Greetings!
This stuff is quite interesting and ingenious! Just thought I'd
mention a few things -- select in libc does something similar, and as
I've mentioned in the previous post we have a beginning hook now into
lisp. CMUCL uses this for job multiplexing to my limited
understanding -- I belie
Greetings!
Robert Boyer <[EMAIL PROTECTED]> writes:
> Presumably, it would be much more efficient to use the Linux C call setitimer
> and have GCL be prepared to accept a SIGALRM and then figure out which
> with-timeout catch, if any, to throw to.
>
Agreed -- and it appears unused so far so we
Greetings!
Just a few other thoughts here to record so that they get handled
eventually:
1) returning unreadable objects from the child, e.g. hash tables
2) limiting the number of concurrent jobs in a sane and nested fashion
3) Having the compiler push a no-side-effects property to the function
Greetings!
John R Harrison <[EMAIL PROTECTED]> writes:
> Curiouser and curiouser. I've just built HOL88 on my old Linux laptop
> (PIII, 2.4.18-5, gcc 2.96). It worked in the end, but I saw a similar
> kind of weird nondeterminism. The first time it failed with an error
> message I didn't really u
Greetings
Robert Boyer <[EMAIL PROTECTED]> writes:
> Here is a simple correction to the description I sent you of the RSA
> decryption algorithm. I must have been asleep. All I have done here is to
> set the constant d to 1.
>
>Now, the RSA decryption computation simply consists of computi
Greetings!
Robert Boyer <[EMAIL PROTECTED]> writes:
> I got a few socket examples to work. Hurray for me!
>
> But I'd appreciate if you'd send me code for the following very simple socket
> application. I can't seem to get IO to work at all. And as usual, trying to
> see what processes are sa
Greetings!
"Warren A. Hunt Jr." <[EMAIL PROTECTED]> writes:
> Hi Bob,
>
> It looks to me as though Camm's si::p-let has an overhead of about 2
> milliseconds on elgin. That seems awfully fast to me! Great in fact. How
> long do you think would be "long" for a fork operation to take? Of
Greetings!
Robert Boyer <[EMAIL PROTECTED]> writes:
> > How about this:
>
> Your implementation does not satisfy the property that it leaves me alone in
> my current GCL to continue work. It also does not satisfy the property that
> it generates an output file name based upon the file being com
Of course all such come with a grain of salt...
I've found a few other posts reporting Linux process creation as 1.8
to 2.5 times slower than thread creation -- much less than the factor
of 10 I was expecting.
Take care,
10 matches
Mail list logo
