`kmsg` is not sufficient

[Drup]

If one wanted to implement, let's say, Lwt_log (with logging function returning threads), kmsg is not sufficient. You need to provide ksmsg. I guess k would be of type string option -> 'a with None on non-message.

[dbuenzli]

I guess k would be of type string option -> 'a with None on non-message.

I don't like this as it constraints all reporters to format to a string.

Of course effects would make this a non-issue. But if we assume we don't have them I'd prefer if we can find some kind of synchronization scheme between the reporter and the continuation.

I guess you concern here is that you don't want k to proceed before the reporter wrote, so simply Lwt.asyncing in the reporter is not enough and we should allow k to sync on it.

[Drup]

I don't like this as it constraints all reporters to format to a string.

I don't think so. You may be able to implement ksmsg with kmsg, maybe by making by changing the type of reporters a bit. I think the key would be to transmit the formatter on which to print to the printing function. This way, a "stringifying" msg function can first print to a string, then delegate to the formatter.

[dbuenzli]

I think the key would be to transmit the formatter on which to print to the printing function.

What do you mean by printing function ? The message formatting function ? That would be annoying.

This way, a "stringifying" msg function can first print to a string, then delegate to the formatter.

This will not work e.g. with colors, since the formatter has rendering style information.

Your initial proposal (string option in the continuation) is also very suspicious since the idea is to decouple logging from actual reporting/formatting which is no longer the case with what you propose. The logger should not see the results of reporting at all, he should only know he can know proceed with k.

[Drup]

Hum, what do you propose ?

[edwintorok]

Could there be a second continuation kdone invoked when the reporter actually finished writing its output? The first continuation would return the 'a Lwt.t side of Lwt.wait () and the second one would invoke Lwt.wakeup, although care should be taken that threads are always woken up even if the reporter is not invoked, or fails.

[dbuenzli]

@edwintorok That may be an idea, do you think this could then be hidden conveniently on the logger side ?

[dbuenzli]

The branch sync-over adds an over client specified callback that is called once the logging is over. I also added a Logs_lwt module that does uses Lwt.wakeup so that synchronous logging becomes possible, maybe I'll add a stdo Lwt reporter aswell in that module. Feedback welcome.

[dbuenzli]

In fact adding over to kmsg adds nothing. Only reporters need such a function. This allows Lwt-aware logging functions to specify a function that the reporters can invoke to unblock the thread they return.

We can't of course make the base logging functions in Logs Lwt-aware, those simply invoke the reporters with fun () -> () and their continuation which won't block.

[dbuenzli]

In fact adding over to kmsg adds nothing.

It would make it easier to define new logging functions with blocking behaviour but that should not be a widespread task. Also not having the over at the client level but hidden behind the implementations of kmsgs allows to avoid a few useless fun calls (or Lwt.waits) whenever the message is not reported.