CPU_TIME_IS_THREAD_LOCAL
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum
10 Feb '03
10 Feb '03
The use of #elif rather than #else in this code
+ #if CPU_TIME_IS_THREAD_LOCAL == YES
+ OBJ2THREAD(Pike_interpreter.thread_id)->auto_gc_time += last_gc_time;
+ #elif CPU_TIME_IS_THREAD_LOCAL == NO
+ auto_gc_time += last_gc_time;
+ #endif
seems to suggest that setting CPU_TIME_IS_THREAD_LOCAL to something
other than `YES' or `NO' is valid, and results in no gc time
accounting at all. Is that correct? In that case I suspect grubba's
fix for the no-treads case is incomplete. If not, why are there two
tests here?
3
5
autodoc
by Peta, jo det �r jag @ Pike developers forum
10 Feb '03
10 Feb '03
Is there anyway to compile the documentation for only a module instead of the
entire tree?
Is there anything like that? I want to compare the performance of pike with
various thread libraries and before writing any test, I'd like to learn
whether anything like that exists.
TIA,
marek
1
0
F_NOTIFY
by Marcus Agehall (Tr�dl�s) @ Pike (-) developers forum
10 Feb '03
10 Feb '03
What is the policy on implementing system-specific functions within
Stdio.File? I've implemented support for the notify-functions within
the Linux kernel which fits very well into the Stdio.File module but
I'm not sure they belong there since they are Linux-specific.
I'd like to see config.log in the pikefarm builds. Could someone
please add it to the list of returned files? (I'm currently interested
in the one in the core directory, but those in the modules might be
interesting another time.)
2
2
Re: gcc/icc
by Mirar @ Pike developers forum
08 Feb '03
08 Feb '03
The correct solution is probably to load Gmp.bignum when it's needed.
I tried to make such a solution, but I couldn't see how without adding
overhead to the bignum creation callbacks.
I was just wondering about one thing - whether it would be a good idea to
tag the APIs in the documentation with the Pike version number where they
appeared? That would enormously help in writing "portable" (as in
cross-pike) scripts.
marek
6
17
werror in C
by Marcus Agehall (Tr�dl�s) @ Pike (-) developers forum
07 Feb '03
07 Feb '03
I need to print debug information from C-code and I want to be able to
use the same syntax as in Pikes werror/write functions. How can I call
werror/write from C?
1
0
Xor
by Peta, jo det �r jag @ Pike developers forum
06 Feb '03
06 Feb '03
({1,2,3,4,1,2}) ^ ({1,2})
gives
({3,4,1,2})
I was expecting ({3,4}), I guess there is a good reason behind it
but I can't figure it out :)
9
48
synchronized
by Martin Stjernholm, Roxen IS @ Pike developers forum
06 Feb '03
06 Feb '03
I've never understood benefit of hiding mutexes like that Java
construct does. It even does so in three different ways depending on
how it's used. Is the code somehow made more clear because the mutexes
disappear? I prefer to see them, so I can tell easily which regions
are synchronized with each other. That also makes it easier to search
on the mutex variable to find those regions.
There's one benefit with a block construct like that: It makes the
region where the lock is held more clear. (The pike way of relying on
refcount garbing of the lock has lead to many bugs, e.g. with the tail
recursion optimization. I don't rely on refcounting for locks anymore;
I always zero them explicitly afterwards.)
So in my view a good synchronized construct would always require a
mutex argument. E.g:
Thread.Mutex my_mutex = Thread.Mutex();
synchronized(my_mutex) void my_first_function() {...}
void my_second_function() {
...
synchronized(my_mutex) {
...
}
}
The second case above is solvable with implicit lambda, but I'd rather
avoid implementing it that way since it "destroys" the syntax so it
can't be upgraded to a better implementation later on (see the blurb
about implicit lambdas in the CHANGES file).
As a transitionary measure, we could perhaps have something like this
instead that works through implicit lambdas:
my_mutex->synchronize() {
...
};
/ Martin Stjernholm, Roxen IS
Previous text:
>2003-02-04 19:14:
>Subject: synchronized
>--------------------------------------------------------------------
>One thing that's nice in Java is the 'synchronized keyword. It would
>be nice to have that functionality in Pike since it's easier than
>manually using mutex locks (nicer code):
>
>
>synchronized void do_something() { ... }
>
>and
>
>mapping foo;
>void do_something() {
> synchronized(foo) {
> work on foo
> }
>}
>
>and
>
>void do_something() {
> ...
> synchronized {
> locked region
> }
> ...
>}
>
>would be nice. The first one creates an implicit mutex lock for the
>entire method, the second one creates a lock bound to a specific
>variable (i.e you can have multiple methods "locking" the same
>variable) and the third method works just like the first, except for a
>specific region rather than the entire method.
>
>Another possibility is to have synchronized classes:
>
>synchronized class {
> ...
>}
>
>and variable instanses:
>
>synchronized mapping foo = ([]);
>
>But the first three versions are IMHO more interesting.
>
>How hard would this be to implement in pike? I'm guessing "quite
>hard", but... :)
>
> / David Hedbor
>