On 04/04/2010 03:34 PM, Pavel Machek wrote:
And then the valid question is... should the api also count virtual
cpus from hyperthreading (aka smt?)?
BOTH should be available. If we're spinning up threads to perform some
processing, then we need to count those virtual cores. But if
advantage.
Cheers,
mark
--
Mark Mielke m...@mielke.cc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
sensibly.
Cheers,
mark
--
Mark Mielke m...@mielke.cc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Stef Walter wrote:
Mark Mielke wrote:
I think fsync() is absolutely necessary to be explicit in this
situation, because the application needs to assert that all data is
written *before* using rename to perform the atomic-change-in-place
effect. I think that anybody who thinks fsync
be to change the spec.
Cheers,
mark
--
Mark Mielke m...@mielke.cc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
that is must is unrealistic. If a lot of
code out there happens to be buggy (for example - close()/rename() from
atomic-change-in-place), then the file system can try to work around
these bugs, but I think it's wrote to say that it must.
Cheers,
mark
--
Mark Mielke m...@mielke.cc
your intent is unreasonable.
Cheers,
mark
--
Mark Mielke m...@mielke.cc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Alexander Larsson wrote:
On Sat, 2009-03-14 at 13:38 -0400, Mark Mielke wrote:
Should sed -i use fsync()? If it
is promising atomic-change-in-place, then it certainly should.
This is the same kind of reasoning that says its ok to do something
because its specified by posix. If its
--
Mark Mielke m...@mielke.cc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
() is a hack.
Just my opinion. :-)
Cheers,
mark
--
Mark Mielke m...@mielke.cc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Mark Mielke wrote:
Putting fsync() on close() is a hack.
Hmm - Looking at the patch, I don't see it doing fsync() on close() - I
should have read from the beginning instead of reacting to the one
person calling the file system semantics broken. :-)
Definitely - any file system operations
mode?) will not
have any problem with the above.
I foresee limited benefit of GC for Gtk+/Glib at this time, as many of
the data structures are reference counted today, and reference counting
PLUS garbage collection is certainly slower than reference counting
alone... :-)
Cheers,
mark
--
Mark
implementation. :-)
But, this is probably a waste of a thread as glib has done what glib has
done.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
that is defined to nothing on systems
that do not support it, or for compatibility. Not saying it should be
done or not - but if it is done, this isn't the first time in history
this compatibility issue has been faced.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED
Dominic Lachowicz wrote:
On Tue, Mar 18, 2008 at 8:46 PM, Mark Mielke [EMAIL PROTECTED] wrote:
Jean Bréfort wrote:
Windows API (and may be DirectX) is a special case, because you can't
write a Windows program without using it.
It's not a special case. There is certainly no reference
Mark Mielke wrote:
If I choose to download Oracle, and connect a GPL product to Oracle
*without redistribution*, there is nothing the FSF can do to stop me.
I should qualify - I went down a path I thought Dominic was leading but
away from the Gtk topic. The above is grey in terms of whether
Paul Pogonyshev wrote:
Mark Mielke wrote:
If I choose to download Oracle, and connect a GPL product to Oracle
*without redistribution*, there is nothing the FSF can do to stop me.
They actually don't. GPL applies only if you distribute modified or
unmodified result. At home
. It took a long time to begin to
understand GPLv2, GPLv3 is still relatively more intimidating.
The GPL has always been scary. The people who were ever comfortable with
it, probably didn't read the fine print.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED
from any conclusion that
the product might require the use of a GPL library or that the product
will function better with the GPL library. Messy.
Anyways - I hope this helps.
Cheers,
mark
--
Mark Mielke [EMAIL PROTECTED]
___
gtk-devel-list mailing
19 matches
Mail list logo
