itself is restricted to a single thread, so it's
> > already the case that no other threads have access to a
> > non-shared variable.
>
> Perhaps my use of the term TLS was unhelpful. I never studied
> multi-threading at the architectural level, so forgive me if my
> unde
dress and cast the pointer to
shared or immutable to be able to pass it across threads. The
variable itself is restricted to a single thread, so it's
already the case that no other threads have access to a
non-shared variable.
Perhaps my use of the term TLS was unhelpful. I never stud
t know quite what
you'd buy by having that, since it's already guaranteed that variables
aren't shared across threads unless you're using shared, __gshared, or
immutable to make it happen. You'd likely to have to use whatever OS
facilities are provided in C to deal with TL
get an answer in their forums but I
doubt it. For Rust I think they based it on that globals should
have some kind of synchronization which is enforced at compile
time. Therefore TLS becomes second citizen.
Speaking of experience, I used to be a C++ programmer. We made
use of thread-local
On 4/1/23 17:02, Ali Çehreli wrote:
Does anyone have documentation on why Rust and Zip does not do thread
local by default?
Rust just does not do mutable globals except in unsafe code.
On 3/26/23 13:41, ryuukk_ wrote:
> C, C++, Rust, Zig, Go doesn't do TLS by default for example
C doesn't do because there was no such concept when it was conceived.
C++ doesn't do because they built on top of C.
(D does because it has always been innovative.)
Go doesn'
On Saturday, 1 April 2023 at 13:11:46 UTC, Guillaume Piolat wrote:
TLS could be explicit and we wouldn't need a -vtls flag.
Yeah, I think what we should do is make each thing be explicitly
marked.
When I want tls, I tend to comment that it was intentional anyway
to make it clear I d
On Saturday, 1 April 2023 at 08:47:54 UTC, IGotD- wrote:
TLS by default is mistake in my opinion and it doesn't really
help. TLS should be discouraged as much as possible as it is
complicated and slows down thread creation.
It looks like a mistake if we consider none of the D-ins
.
But you kind of get into the same things with "accidental TLS".
It doesn't race, but now the variable is different for every
thread, which is a different kind of race.
TLS could be explicit and we wouldn't need a -vtls flag. There is
no flag to warn for every use of @trus
On Sunday, 26 March 2023 at 18:25:54 UTC, Richard (Rikki) Andrew
Cattermole wrote:
Having TLS by default is actually quite desirable if you like
your code to be safe without having to do anything extra.
As soon as you go into global to the process memory, you are
responsible for
On Sunday, 26 March 2023 at 18:25:54 UTC, Richard (Rikki) Andrew
Cattermole wrote:
Having TLS by default is actually quite desirable if you like
your code to be safe without having to do anything extra.
As soon as you go into global to the process memory, you are
responsible for
On Friday, 31 March 2023 at 16:26:36 UTC, ryuukk_ wrote:
I disagree, global mutables are not bad
That the same bad advice as telling people to "embrace OOP and
multiple inheritance" and all the Java BS
"just put your variable into a class and make it static, and
then have your singleton to
On Friday, 31 March 2023 at 16:26:36 UTC, ryuukk_ wrote:
That the same bad advice as telling people to "embrace OOP and
multiple inheritance" and all the Java BS
"just put your variable into a class and make it static, and
then have your singleton to access your static variables"
I agree tha
On Friday, 31 March 2023 at 16:02:35 UTC, Dennis wrote:
On Friday, 31 March 2023 at 15:52:21 UTC, ryuukk_ wrote:
the point i bring is ``__gshared`` is ugly, so we want an ugly
language?
Good code shouldn't look ugly, but global mutable variables are
bad, so it's appropriate that they look ugl
On Friday, 31 March 2023 at 15:52:21 UTC, ryuukk_ wrote:
the point i bring is ``__gshared`` is ugly, so we want an ugly
language?
Good code shouldn't look ugly, but global mutable variables are
bad, so it's appropriate that they look ugly.
You can still put a single `__gshared:` at the top o
that happen at runtime, so
it can't find races in code paths that are not executed
https://go.dev/doc/articles/race_detector
If you want TLS in GO, you specify that you need a TLS variable,
just like every sane languages
Go went the smart route on top of having goroutines, making it
sup
On Friday, 31 March 2023 at 10:26:32 UTC, Nick Treleaven wrote:
On Sunday, 26 March 2023 at 20:39:21 UTC, ryuukk_ wrote:
if my code doesn't do threads, why should i put my variable
into TLS?
I don't think writing __gshared is much of a burden. You can
use -vtls to print out all
On Monday, 27 March 2023 at 08:44:41 UTC, wjoe wrote:
e.g.: It used to be faster to ...
- pre-calculate sin/cos tables, now the memory look up cost
more cycles than the calculation itself
...
- only redraw the parts of the screen that changed, now the
branching is slower than to redraw eve
On Sunday, 26 March 2023 at 20:36:37 UTC, ryuukk_ wrote:
Golang doesn't even have thread local storage, yet they do very
well
Go doesn't have a solution to preventing data races at compile
time, they just say don't share memory. But what if you
accidentally share memory? That is *very* easy t
On Sunday, 26 March 2023 at 20:39:21 UTC, ryuukk_ wrote:
if my code doesn't do threads, why should i put my variable
into TLS?
I don't think writing __gshared is much of a burden. You can use
-vtls to print out all variables that are TLS, and add that to an
automated test to check
On Sunday, 26 March 2023 at 20:39:21 UTC, ryuukk_ wrote:
if my code doesn't do threads, why should i put my variable
into TLS?
I don't think writing __gshared is a huge burden. You can use
-vtls to print out all variables that are TLS, and add that to an
automated test to check
On 3/26/23 4:41 PM, ryuukk_ wrote:
On Sunday, 26 March 2023 at 19:08:32 UTC, Steven Schveighoffer wrote:
On 3/26/23 2:07 PM, ryuukk_ wrote:
Hi,
It's common knowledge that accessing tls global is slow
http://david-grs.github.io/tls_performance_overhead_cost_linux/
What i do not under
On Sunday, 26 March 2023 at 18:07:03 UTC, ryuukk_ wrote:
Even C does it better:
https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html
Honestly I find TLS-by-default to be a bad idea, it has become a
trap to be avoided, and TLS does occasionally speed up things but
it should be opt-in.
On Sunday, 26 March 2023 at 18:07:03 UTC, ryuukk_ wrote:
What i do not understand is the reasoning behind choosing tls
global by default in D
Because the language maintainers decided that they want to
emphasize the actor model with no default shared state in the
language.
This is quite
On Sunday, 26 March 2023 at 18:07:03 UTC, ryuukk_ wrote:
``shared`` is even more ugly since everything must be shared
afterwards
The limitations of `shared` can be bypassed with a "function"
that removes type qualifiers. `return *cast(Unqual!T*)
&foo`(example, doesn't work as is for arrays.)
On Sunday, 26 March 2023 at 18:07:03 UTC, ryuukk_ wrote:
``shared`` is even more ugly since everything must be shared
afterwards
The limitations of `shared` can be bypassed with a "function"
that removes type qualifiers. `return *cast(Unqual!T*)
&foo`(example, doesn't work as is for arrays.)
On Sunday, 26 March 2023 at 18:07:03 UTC, ryuukk_ wrote:
``shared`` is even more ugly since everything must be shared
afterwards
The limitations of `shared` can be bypassed with a "function"
that removes type qualifiers. `return *cast(Unqual!T*)
&foo`(example, doesn't work as is for arrays.)
On Sunday, 26 March 2023 at 18:07:03 UTC, ryuukk_ wrote:
It should be the opposite
Slow code ugly
Fast code beautiful
What's fast today may not be fast tomorrow but the language might
still be relevant.
e.g.: It used to be faster to ...
- pre-calculate sin/cos tables, now the memory look
On Sunday, 26 March 2023 at 18:07:03 UTC, ryuukk_ wrote:
``shared`` is even more ugly since everything must be shared
afterwards
The limitations of `shared` can be bypassed with a "function"
that removes type qualifiers. `return *cast(Unqual!T*)
&foo`(example, doesn't work as is for arrays.)
On Sunday, 26 March 2023 at 19:08:32 UTC, Steven Schveighoffer
wrote:
On 3/26/23 2:07 PM, ryuukk_ wrote:
Hi,
It's common knowledge that accessing tls global is slow
http://david-grs.github.io/tls_performance_overhead_cost_linux/
What i do not understand is the reasoning behind choosin
On Sunday, 26 March 2023 at 18:25:54 UTC, Richard (Rikki) Andrew
Cattermole wrote:
Having TLS by default is actually quite desirable if you like
your code to be safe without having to do anything extra.
As soon as you go into global to the process memory, you are
responsible for
used. And if you
need it, you won't be worried about how the storage class looks
because you'll be concentrating on if your design is
thread-safe.
I don't understand this argument, if my code doesn't do threads,
why should i put my variable into TLS?
If i want fast cod
On 3/26/23 2:07 PM, ryuukk_ wrote:
Hi,
It's common knowledge that accessing tls global is slow
http://david-grs.github.io/tls_performance_overhead_cost_linux/
What i do not understand is the reasoning behind choosing tls global by
default in D
If you know a variable is not `shared`,
On Sunday, 26 March 2023 at 18:07:03 UTC, ryuukk_ wrote:
What i find even more weird is writing fast code is ugly in D
Look at this ugly code
```D
__gshared int fast_code_ugly;
```
Because it should be rare that __gshared is used. And if you need
it, you won't be worried about how the storag
With -betterC it's broken for 3 years btw:
https://issues.dlang.org/show_bug.cgi?id=20737
Having TLS by default is actually quite desirable if you like your code
to be safe without having to do anything extra.
As soon as you go into global to the process memory, you are responsible
for synchronization. Ensuring that the state is what you want it to be.
Keep in mind that threads
Perhaps in ``-betterC`` tls vars should be annotated with
``@tls``, and the default is not tls just like in C?
Hi,
It's common knowledge that accessing tls global is slow
http://david-grs.github.io/tls_performance_overhead_cost_linux/
What i do not understand is the reasoning behind choosing tls
global by default in D
What i find even more weird is writing fast code is ugly in D
Look at this
On Saturday, 30 January 2021 at 12:28:16 UTC, Ali Çehreli wrote:
On 1/30/21 1:34 AM, Imperatorn wrote:
> [...]
should be
> [...]
I wonder whether doing something in the runtime is possible.
For example, it may be more resilient and not crash when
suspending a thread fails because the thread m
its are very limited.
Back to topic. I think that the generic solution even if it
doesn't help you with your current implementation is to ban TLS
all together. I think there have already been requests to remove
TLS for druntime/phobos totally and I think this should
definitely be done soone
On 1/30/21 1:34 AM, Imperatorn wrote:
> With this knowledge we have now, what changes could and/or should be
> made to make this process easier? 🤔
I wonder whether doing something in the runtime is possible. For
example, it may be more resilient and not crash when suspending a thread
fails bec
On Saturday, 30 January 2021 at 05:44:37 UTC, Ali Çehreli wrote:
On 1/24/21 2:28 AM, IGotD- wrote:
> [...]
course. Any
> [...]
not do D
> [...]
[...]
Hmm, interesting, or what you should call it 😅
With this knowledge we have now, what changes could and/or should
be made to make this process
On 1/24/21 2:28 AM, IGotD- wrote:
> Any threads started by druntime has proper initialization of course. Any
> thread started by any module written in another language will not do D
> the thread initialization.
And that of course has been what I've been trying to deal with. Bugs in
the uses of
On Thursday, 28 January 2021 at 00:58:17 UTC, rikki cattermole
wrote:
On 28/01/2021 1:16 PM, tsbockman wrote:
The documentation build on dlang.org is broken. Check the
source code or Adam D. Ruppe's dpldocs.info for the complete
documentation:
http://dpldocs.info/experimental-docs/core.thread.
On 28/01/2021 1:16 PM, tsbockman wrote:
The documentation build on dlang.org is broken. Check the source code or
Adam D. Ruppe's dpldocs.info for the complete documentation:
http://dpldocs.info/experimental-docs/core.thread.osthread.html
Fixed: https://issues.dlang.org/show_bug.cgi?id=21309
On Sunday, 24 January 2021 at 03:59:26 UTC, Ali Çehreli wrote:
I am surprised how much I had learned at that time and how much
I've already forgotten. :/ For example, my PR involves
thread_setThis, which seems to be history now:
https://docarchives.dlang.io/v2.068.0/phobos/core_thread.html#.t
On Sunday, 24 January 2021 at 03:59:26 UTC, Ali Çehreli wrote:
That must be the case for threads started by D runtime, right?
It sounds like I must call rt_moduleTlsCtor explicitly for
foreign threads. It's still not clear to me which modules' TLS
variables are initialized (c
e main thread, thread_attachThis is performed what I
> have seen.
That explains why everything just works on most cases.
> Actual ctor code that runs for each TLS thread is language specific and
> not part of the ELF standard therefore no such TLS ctor code are being
> run in the lower level API.
, thread_attachThis is performed
what I have seen.
Another question: Are TLS ctors executed when I do loadLibrary?
And when they are executed, which modules are involved? The
module that is calling rt_moduleTlsCtor or all modules? What
are "all modules"?
The TLS standard (at least the EL
do thread_attachThis? I ask
because I have a library that is loaded by Python and things work even
*without* calling thread_attachThis.
- Execute thread local storage (TLS) ctors: Again, this happens
automatically for most cases. However, thread_attachThis says "[if] full
functionality as
On Tuesday, 27 October 2020 at 17:36:53 UTC, Dukc wrote:
```
HTTP connection handler has thrown: Accepting SSL tunnel:
error:1408F09C:SSL routines:ssl3_get_record:http request
(336130204)
```
I figured out from the Vibe.D source code that if I enable the
debug level of the console logger, I
I have a Vibe.D server binary that, locally at least, works. But
only without TLS. I want to add TLS to it and test it locally
with a self-signed certificate. I made one with LibreSSL, stored
in `cert.crt` and `key.key`. The application main function:
```
shared static this()
{ import
On 2020-06-26 15:16, Adam D. Ruppe wrote:
Yeah, I've been wanting to change that and use the native apis for years
but like I just haven't been able to figure out the documentation of them.
That would be nice.
That's the problem of everything Apple makes. Kinda drives me nuts
trying to keep
issue assuming libcurl is built
with the platform provided TLS implementation. Just make sure it's
possible to statically link libcurl, without using `dlopen`.
--
/Jacob Carlborg
On 2020-06-26 14:41, Kagamin wrote:
Maybe just start wget or something like that?
The point was to avoid runtime dependencies.
Since you want the latest certificate storage, you intend to support
only the latest system. Many root certificates will timeout now.
I didn't say the latest certi
On Friday, 26 June 2020 at 10:12:09 UTC, Jacob Carlborg wrote:
* Arsd [4]. Relies on OpenSSL
Yeah, I've been wanting to change that and use the native apis
for years but like I just haven't been able to figure out the
documentation of them.
Though for plain download, on Windows there's a hi
On Friday, 26 June 2020 at 10:12:09 UTC, Jacob Carlborg wrote:
Downloading files over TLS. This seems that it's something that
should be quite simple to do. My high level goals are
cross-platform and easy distribution. I don't need anything
fancy just a simple API like this:
downl
tform provided
implementation of TLS on Windows.
* Are there any high level APIs, like NSURLSession, on Windows
that can be used to download files?
It is possible to statically link libcurl into your application.
No need to use OpenSSL as libcurl can be built with SChannel.
On Friday, 26 June 2020 at 11:41:27 UTC, Jacob Carlborg wrote:
On Friday, 26 June 2020 at 11:10:27 UTC, ikod wrote:
[...]
Oh, it's that bad. That's disappointing.
[...]
I'm using a script (written in D) in my tool, DStep [1][2], to
identify which versions of libclang is available and to
ing on Windows either.
macOS is my main platform.
Bottom line - problem with SSL/TLS libraries lies in
incompatibility between platforms and even inside the single
library.
Yes. I'm trying to identify the best solution, which ideally
requires the least amount of work.
[1]
https://git
On Friday, 26 June 2020 at 10:12:09 UTC, Jacob Carlborg wrote:
Downloading files over TLS. This seems that it's something that
should be quite simple to do. My high level goals are
cross-platform and easy distribution. I don't need anything
fancy just a simple API like this:
downl
Downloading files over TLS. This seems that it's something that
should be quite simple to do. My high level goals are
cross-platform and easy distribution. I don't need anything fancy
just a simple API like this:
download("https://url.com";, "/local/file");
Be
On Monday, 11 September 2017 at 22:38:21 UTC, Walter Bright wrote:
If an address is taken to a TLS object, any relocations and
adjustments are made at the time the pointer is generated, not
when the pointer is dereferenced.
Could you elaborate on that explanation more? The way I thought
On 09/11/2017 03:38 PM, Walter Bright wrote:
> If an address is taken to a TLS object, any relocations and adjustments
> are made at the time the pointer is generated, not when the pointer is
> dereferenced. Hence, the pointer may be passed from thread to thread,
> and will still
f the terms 'thread' and 'process'. I use thread to mean basically a
stack, plus register set, a cpu execution context, but has nothing to do with
virtual memory spaces or o/s ownership of resources, the one exception being a
tls space, which by definition is one-per-thread.
On 09/11/2017 01:51 AM, John Burton wrote:
> I wrote this program :-
>
> import std.stdio;
> import std.concurrency;
>
> int data;
>
> void display()
> {
> writeln("Address is ", &data);
> }
>
> void main()
> {
> auto tid1 = spawn(&display);
> auto tid2 = spawn(&display);
> auto t
ership of
resources, the one exception being a tls space, which by
definition is one-per-thread. A process is one or more threads
plus an address space and a set of all the resources owned by
the process according to the o/s. I'm just saying this so you
know how I'm used to approv
On Wednesday, 6 September 2017 at 15:55:35 UTC, Ali Çehreli wrote:
On 09/06/2017 08:27 AM, Cecil Ward wrote:
> If someone has some static data somewhere, be it in tls or
marked shared
> __gshared or immutable or combinations (whatever), and
someone takes the
> address of it and pass tha
On 09/06/2017 08:27 AM, Cecil Ward wrote:
> If someone has some static data somewhere, be it in tls or marked shared
> __gshared or immutable or combinations (whatever), and someone takes the
> address of it and pass that address to some other routine of mine that
> does not have a
If someone has some static data somewhere, be it in tls or marked
shared __gshared or immutable or combinations (whatever), and
someone takes the address of it and pass that address to some
other routine of mine that does not have access to the source
code of the original definition of the
.
immutable variables are also not put in TLS.
Thank you for yours replys but there is a tls directory even when I
compile empty main..
It's very likely that there are TLS variables in druntime that are
linked in. You can identify them by looking at the map file.
On Friday, 10 March 2017 at 06:41:46 UTC, M-exe wrote:
I found that D is great language, but for my own reasons I'm
trying to use it without TLS at all.
Can the TLS directory be avoided? (compiling on windows)
I don't know what you mean by the TLS directory, can you explain?
I me
put in TLS.
Thank you for yours replys but there is a tls directory even when
I compile empty main..
On Friday, 10 March 2017 at 19:24:29 UTC, bauss wrote:
Mark your variables with __gshared. I would say shred, but it
has some restrictions to it, where __gshared is the equivalent
to global variables in C.
immutable variables are also not put in TLS.
On Friday, 10 March 2017 at 07:33:44 UTC, M-exe wrote:
On Friday, 10 March 2017 at 07:17:22 UTC, rikki cattermole
wrote:
D does not support Windows XP.
If you absolutely require it, you will have to contact Walter
about support.
Let me care about it ;)
I just need help with the TLS :)
Mark
On Friday, 10 March 2017 at 07:17:22 UTC, rikki cattermole wrote:
D does not support Windows XP.
If you absolutely require it, you will have to contact Walter
about support.
Let me care about it ;)
I just need help with the TLS :)
On 10/03/2017 8:06 PM, M-exe wrote:
On Friday, 10 March 2017 at 06:46:03 UTC, rikki cattermole wrote:
On 10/03/2017 7:41 PM, M-exe wrote:
I found that D is great language, but for my own reasons I'm trying to
use it without TLS at all.
Can the TLS directory be avoided? (compiling on wi
On Friday, 10 March 2017 at 06:46:03 UTC, rikki cattermole wrote:
On 10/03/2017 7:41 PM, M-exe wrote:
I found that D is great language, but for my own reasons I'm
trying to
use it without TLS at all.
Can the TLS directory be avoided? (compiling on windows)
I mean, can it avoided wi
On 10/03/2017 7:41 PM, M-exe wrote:
I found that D is great language, but for my own reasons I'm trying to
use it without TLS at all.
Can the TLS directory be avoided? (compiling on windows)
I mean, can it avoided without losing GC and main language features?
I found out that also when
I found that D is great language, but for my own reasons I'm
trying to use it without TLS at all.
Can the TLS directory be avoided? (compiling on windows)
I mean, can it avoided without losing GC and main language
features?
I found out that also when with -vtls there is no output, ther
On 07/28/2016 12:38 AM, Dechcaudron wrote:
Giving my 20 votes to the issue (are votes even taken into account?). At
least now I know the source of attribute-enforcements breakdown is
basically delegate management. That should help me out enough so I don't
have this issue anymore.
Thanks a bunch.
On Wednesday, 27 July 2016 at 20:54:00 UTC, ag0aep6g wrote:
Looks pretty bad. There's an open issue on this:
https://issues.dlang.org/show_bug.cgi?id=16095
Giving my 20 votes to the issue (are votes even taken into
account?). At least now I know the source of
attribute-enforcements breakdown
On 07/27/2016 09:19 PM, Dechcaudron wrote:
struct Foo
{
[...]
void ping() shared
{
[...]
}
void fire()
{
spawn(&explode);
}
void explode() shared
{
ping();
}
}
void main()
{
auto a = Foo(1, 2);
a.fire();
thread_joinAll();
}
I keep getting data from within a struct shared across threads
for apparently no reason: the code is the following:
import std.stdio;
import std.concurrency;
import core.thread : Thread, thread_joinAll;
struct Foo
{
int a;
int b;
this(int a, int b)
{
this.a = a;
I realize this shouldn't belong in D.learn :)
http://forum.dlang.org/thread/m4aahr$25qd$2...@digitalmars.com#post-m4aahr:2425qd:242:40digitalmars.com
I always wondered why we would use the shared keyword on GC allocations
if only the stack can be optimized for TLS Storage.
After thinking about how shared objects should work with the GC, it's
become obvious that the GC should be optimized for local data. Anything
shared would have
have __tls_get_addr,
which is unique in that it is provided by the runtime linker from
glibc. You may want to try out my Android patch for dmd, which
doesn't use native TLS and doesn't rely on that function either:
http://164.138.25.188/dmd/packed_tls_for_elf.patch
You'll want to get rid of
On Friday, 3 October 2014 at 10:47:11 UTC, David Nadlinger wrote:
On Friday, 3 October 2014 at 08:47:07 UTC, Atila Neves wrote:
ld: <...>/libphobos2.a(sections_linux_570_420.o): undefined
reference to symbol '__tls_get_addr@@GLIBC_2.3'
/lib64/ld-linux-x86-64.so.2: error adding symbols: DSO
On Friday, 3 October 2014 at 10:47:11 UTC, David Nadlinger wrote:
On Friday, 3 October 2014 at 08:47:07 UTC, Atila Neves wrote:
ld: <...>/libphobos2.a(sections_linux_570_420.o): undefined
reference to symbol '__tls_get_addr@@GLIBC_2.3'
/lib64/ld-linux-x86-64.so.2: error adding symbols: DSO
On Friday, 3 October 2014 at 08:47:07 UTC, Atila Neves wrote:
ld: <...>/libphobos2.a(sections_linux_570_420.o): undefined
reference to symbol '__tls_get_addr@@GLIBC_2.3'
/lib64/ld-linux-x86-64.so.2: error adding symbols: DSO
missing from command line
collect2: error: ld returned 1 e
Both the pre-compiled dmd and building it from source from git
HEAD give me the same result. I'm trying to compile D programs on
an ancient Linux distro I have no root access to and hence no
control over (don't ask). Its libc is so old I can't compile gcc
4.9 on it (gcc 4.8 is the most recent o
Thanks for response. I think this would help with my problem.
You can also use OpenSSL. I wrote a little wrapper class that
extends std.socket.Socket for it:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/sslsocket.d
If you download that file and compile it with your app:
dmd yourfile.d sslsocket.d
you s
On Wednesday, 29 January 2014 at 09:07:18 UTC, Uranuz wrote:
In this case I want client programme on D that will communicate
with some server over secure HTTP. I want to be able to update
DNS records via it's web API using web interface of my web
application written on D. I could do it using some
In this case I want client programme on D that will communicate
with some server over secure HTTP. I want to be able to update
DNS records via it's web API using web interface of my web
application written on D. I could do it using some cross-site
request on JavaScript XmlHTTPRequest, but I want t
On Wednesday, 29 January 2014 at 07:20:52 UTC, Uranuz wrote:
I continue to practice with web applications on D and I have
some questions about secure protocols of data transmissions. I
don't have any experience with SSL/TLS so I need an advice how
to get started. Is there any ready sol
I continue to practice with web applications on D and I have some
questions about secure protocols of data transmissions. I don't
have any experience with SSL/TLS so I need an advice how to get
started. Is there any ready solution how to create client based
on secured socket (for example
I'm currently playing around with D's compile time introspection and I'm
trying to do the following:
1. Detect if a member is static
2. Detect if a member is __gshared
3. Get the TLS offset of a static variable (at compile time...)
I would be glad if anyone could help me with o
On 06/23/2012 09:51 PM, Alex Rønne Petersen wrote:
Hi,
Does taking the address of a TLS variable and passing it to other
threads have defined semantics? I would assume it results in a pointer
to the thread's instance of the TLS variable (which makes sense),
I'd assume that it re
Hi,
Does taking the address of a TLS variable and passing it to other
threads have defined semantics? I would assume it results in a pointer
to the thread's instance of the TLS variable (which makes sense), but is
passing it to other threads OK? Does the language guarantee this?
--
1 - 100 of 110 matches
Mail list logo
