Re: How to implement Canceleable spawn() from parent
On 6/29/20 4:34 PM, aberba wrote: > So with this, without the Thread.sleep() to block main from exiting, the > spawned thread will terminate immediately. You can call core.thread.thread_joinAll at the end of main. Another way would be to wait for a worker's exit by looking for LinkTerminated but you need to start the thread with spawnLinked: http://ddili.org/ders/d.en/concurrency.html#ix_concurrency.LinkTerminated Ali
Re: How to implement Canceleable spawn() from parent
On Sunday, 28 June 2020 at 14:23:01 UTC, Stanislav Blinov wrote: On Sunday, 28 June 2020 at 13:29:08 UTC, aberba wrote: [...] The error you're getting is because you're passing a pointer to a delegate instead of a delegate. [...] So with this, without the Thread.sleep() to block main from exiting, the spawned thread will terminate immediately. How do I keep it from happening? Keep it running continuously? From the docs, it says OwnerTerminated exception gets thrown when the sending thread (e.i. main) is terminated. Thrown on calls to receive if the thread that spawned the receiving thread has terminated and no more messages exist.
Re: scope guard question
On Monday, 29 June 2020 at 22:31:12 UTC, Arjan wrote: So when no inner scope is present, the scope exit 'runs' after the return? Is that indeed expected behavior according to the specification? Yes. A scope ends at the '}'. Destructors and scope guards execute then, after the return.
Re: scope guard question
On 6/29/20 6:31 PM, Arjan wrote:
```
void main()
{
import std.stdio;
auto f = (){
string[] t;
{ // inner scope
t ~= "hello";
scope( exit ) t ~= "world";
} // inner scope exit
return t;
};
f().writeln; // ["hello", "world"]
}
```
removing the inner scope in f() gives ["hello"]
So when no inner scope is present, the scope exit 'runs' after the
return? Is that indeed expected behavior according to the specification?
Yes. The return statement is inside the scope of the function, so it
runs before the scope is exited. Are you saying the spec doesn't say that?
-Steve
scope guard question
```
void main()
{
import std.stdio;
auto f = (){
string[] t;
{ // inner scope
t ~= "hello";
scope( exit ) t ~= "world";
} // inner scope exit
return t;
};
f().writeln; // ["hello", "world"]
}
```
removing the inner scope in f() gives ["hello"]
So when no inner scope is present, the scope exit 'runs' after
the return? Is that indeed expected behavior according to the
specification?
Re: Calling C functions
On 6/29/20 1:50 PM, Jacob Carlborg wrote: On Monday, 29 June 2020 at 16:34:33 UTC, Steven Schveighoffer wrote: Are you sure? On the ABI page [1] , it says "The extern (C) and extern (D) calling convention matches the C calling convention used by the supported C compiler on the host system." In that case the documentation is wrong. Here's an example showing the differences: Yep, for sure. I'll file an issue. Anyone know why the calling convention would differ? -Steve
Re: Calling C functions
On Monday, 29 June 2020 at 16:34:33 UTC, Steven Schveighoffer
wrote:
Are you sure? On the ABI page [1] , it says "The extern (C) and
extern (D) calling convention matches the C calling convention
used by the supported C compiler on the host system."
In that case the documentation is wrong. Here's an example
showing the differences:
$ cat foo.c
#include
void foo(int a, int b)
{
printf("a=%d b=%d\n", a, b);
}
$ clang -c foo.c
$ cat main.d
pragma(mangle, "foo") extern (D) void foo_extern_d(int, int);
pragma(mangle, "foo") extern (C) void foo_extern_c(int, int);
void main()
{
foo_extern_d(1, 2);
foo_extern_c(1, 2);
}
$ dmd main.d foo.o
$ ./main
a=2 b=1
a=1 b=2
This is on macOS.
--
/Jacob Carlborg
Re: Calling C functions
On 6/26/20 4:15 AM, Jacob Carlborg wrote:
On Friday, 26 June 2020 at 00:30:22 UTC, Denis wrote:
I have a two questions about calling C functions from D.
(1) When passing a D callback to a C function, is there a way to write
the code without having to prefix the callback declaration with
"extern(C)"?
It's not a big deal adding the prefix to the D function declaration.
It just seems odd to me to prefix D code with "extern(C)". For
example, the following code works:
extern(C) void cfunc(void function(int));
extern(C) void dcallback(int x) {...} <-- Why extern(C)?
cfunc();
Can this be rewritten, dropping the prefix from the second line? If
not, it would be helpful to know why "extern(C)" is needed here too.
No, it cannot be dropped. `extern(C)` is required because C and D are
using different calling conventions (D functions are also mangled). For
example, D (at least DMD and LDC) are passing the arguments to the
function in reverse.
Are you sure? On the ABI page [1] , it says "The extern (C) and extern
(D) calling convention matches the C calling convention used by the
supported C compiler on the host system."
I'm pretty sure you can use function pointers to D functions for C
callbacks, and it should work.
-Steve
[1] https://dlang.org/spec/abi.html#function_calling_conventions
Re: Light-weight runtime
On Sunday, 28 June 2020 at 07:09:53 UTC, Виталий Фадеев wrote: I want light-weight runtime ! How to ? Runtime provides language features that rely on extra code. Removing that code from runtime means to give up on corresponding language features. This way you can implement only features you want or even reduce runtime to almost zero. You can start by not linking your code with druntime and see what's missing and see if you can evade or implement the feature.
Re: Waiting on file descriptor/socket *AND* thread messages
On Monday, 29 June 2020 at 12:25:16 UTC, Steven Schveighoffer wrote: On 6/29/20 5:14 AM, ichneumwn wrote: [...] Not in the standard library. Such things require an event framework, because there is no OS-agnostic provided mechanism to sleep on all these things at once. I recommend looking through code.dlang.org. I found these: https://code.dlang.org/packages/libasync https://code.dlang.org/packages/eventcore https://code.dlang.org/packages/mecca (this seems very underdocumented, but I know it provides such a system) [...] I don't know the correct way to solve this, I've done it in the past by creating a file descriptor that can be waited on to wake up the target along with any other file descriptors being waited on. -Steve Thanks for the pointers Steve!
Re: Waiting on file descriptor/socket *AND* thread messages
On 6/29/20 5:14 AM, ichneumwn wrote: Dear all, Is there some facility in D for a single statement/function call that will wait on both file descriptors, like Socket.select(), and will also wake up when there is something to be receive()'d? Not in the standard library. Such things require an event framework, because there is no OS-agnostic provided mechanism to sleep on all these things at once. I recommend looking through code.dlang.org. I found these: https://code.dlang.org/packages/libasync https://code.dlang.org/packages/eventcore https://code.dlang.org/packages/mecca (this seems very underdocumented, but I know it provides such a system) One solution would be to have my main thread use receive() and a helper thread that does the select() call and sends a message to the main thread. That seems a bit of overkill however. I don't know the correct way to solve this, I've done it in the past by creating a file descriptor that can be waited on to wake up the target along with any other file descriptors being waited on. -Steve
Re: [DIP1000] Something I don't quite understand regarding 'scope'
On Monday, 29 June 2020 at 06:21:43 UTC, ag0aep6g wrote: Since `local` and `writeln` are templates, the attributes for their parameters are inferred from their bodies. `local!(int*)` doesn't do anything with the parameter, so it's inferred as `scope`. `writeln!(int*)` apparently does something that prevents `scope` from being inferred. Thanks. It would appear indeed that inference fails for some reason. Explicitly marking args as 'scope' for `writeln` and `File.write` lets them compile. I wonder if there's a way to find exactly what it is in either of those that prevents the compiler from inferring 'scope'.
Re: Linking D with C structs
On Monday, 29 June 2020 at 06:29:38 UTC, Anthony wrote: What does "__initZ" refer to? Does this refer to automatic initialization like "this()"? Almost, it's the static initializer for that struct, which is omitted because you apparently don't compile/link the module containing the struct declaration. Initialize the char array with zeros (= 0) to make the struct fully zero-initialized, preventing the need for that symbol. chars in D are initialized with 0xFF, unlike byte and ubyte.
Waiting on file descriptor/socket *AND* thread messages
Dear all, Is there some facility in D for a single statement/function call that will wait on both file descriptors, like Socket.select(), and will also wake up when there is something to be receive()'d? One solution would be to have my main thread use receive() and a helper thread that does the select() call and sends a message to the main thread. That seems a bit of overkill however. Apologies if this has been asked before, but my google search and search in this thread were fruitless (could be my searching skills) Cheers
Linking D with C structs
Hello,
I'm trying to hand write some bindings to mongo-c-driver. (For
learning purposes and to get the latest bindings).
My binding code to convert to mongoc/mongoc.d
is:
= c interop file
module mongoc/mongoc.d;
import core.stdc.stdint;
extern (c) {
struct {
uint domain;
uint code;
char[504] message; //when this exists, the code does not
compile
}
}
===
= build script
export
LD_LIBRARY_PATH=mongo-c-driver/cmake-build/src/libmongoc:mongo-c-driver/cmake-build/src/libbson:$LD_LIBRARY_PATH
dmd hello_mongo.d \
-I=mongo-c-driver/src/libmongoc/src/ \
-I=mongo-c-driver/src/libbson/src/ \
-I=mongo-c-driver/cmake-build/src/libbson/src/bson/ \
-I=mongo-c-driver/cmake-build/src/libmongoc/src/mongoc \
-L=-Lmongo-c-driver/cmake-build/src/libmongoc \
-L=-Lmongo-c-driver/cmake-build/src/libbson \
-L=-lmongoc-1.0 \
-L=-lbson-1.0 \
./hello_mongo
However, when I add the message field in the struct, I cannot
compile the code:
ld: hello_mongo.o: in function `_Dmain':
hello_mongo.d:(.text._Dmain[_Dmain]+0x1a): undefined reference to
`_D6mongoc6mongoc13_bson_error_t6__initZ'
What does "__initZ" refer to?
Does this refer to automatic initialization like "this()"?
Re: [DIP1000] Something I don't quite understand regarding 'scope'
On 29.06.20 02:28, Stanislav Blinov wrote:
void local(Args...)(Args args)
{
}
void main() @safe
{
import std.stdio;
scope int* p;
local(p); // Ok
writeln(p); // Error: scope variable p assigned to non-scope
parameter _param_0 calling std.stdio.writeln!(int*).writeln
}
The signatures of `std.stdio.writeln` and `local` are the same (see
`writeln` [1]). Yet, with '$ dmd -preview=dip1000' the call to `local`
compiles, while the call to `writeln` doesn't.
Since `local` and `writeln` are templates, the attributes for their
parameters are inferred from their bodies. `local!(int*)` doesn't do
anything with the parameter, so it's inferred as `scope`.
`writeln!(int*)` apparently does something that prevents `scope` from
being inferred.
Re: How to implement Canceleable spawn() from parent
I'm doing this in an X11 application in order to send a timer
event every 100 milliseconds to the main event queue.
class Application
{
shared private bool s_tick;
void clock_task (shared X11.Display* disp, X11.Atom atom,
X11.Window win)
{
for (;;)
{
try
{
receiveTimeout (100.msecs);
if (disp && atomicLoad(s_tick))
{
// disable ticking until it is allowed again at the end
of the event loop
atomicStore(s_tick, false);
X11.XClientMessageEvent event;
event.type = X11.ClientMessage;
event.window = win;
event.message_type = atom;
event.format = 32;
event.data.l = [0, 0, 0, 0, 0];
X11.XSendEvent (cast (X11.Display*) disp, win, 0, 0,
cast(X11.XEvent*));
X11.XFlush (cast (X11.Display*) disp);
}
}
catch (Throwable)
{
return;
}
}
}
this ()
{
...
spawn (_task, cast(shared)x11Display, x11SigClockAtom,
_x11_proxyWindow);
}
run ()
{
while (true)
{
...
// event processing starts here: read in X11 event and
convert it to a wit Event
X11.XEvent x11_event;
X11.XNextEvent (_x11.display, _event);
...
atomicStore(s_tick, true);
}
}
}
